> From past experience, distros tend to find many small issues with build > systems, especially debian who have tones of scripts to verify what > changed in the package: a missing installed file, a missing build > option, missing build flag, etc. You can either deal with that and roll > a quick point release to fix any issue they could find, or keep both > build systems for a couple releases while recommending downstream (a > note in ChangeLog) to try the meson build system, making it clear > autotools is going away. Another viewpoint is supporting both for a number of releases equates to kicking the can down the road. A lot of people don't bother with changes until they're forced to. Consider supporting both build systems for one release, making it clear autotools will be removed from the next release. If you imply a sense of urgency, people are more likely to give it attention. If you imply that it's ok to kick the can down the road, people will kick the can down the road. Yes, some people will jump on the move to meson, but it's not just those people who need to migrate. The best way to get someones attention is not text in a changelog or readme, it's to deploy changes that break their build and make them address it. How many times has it been that upcoming changes were announced well in advance and people still neglect preparation. As the saying goes, `the squeaky wheel gets the grease`.
