Sometimes you need to introduce backward incompatibile changes, when the improvements far outweighs the downsides. It is possible to easily switch to old behavior, but the user must be aware of such changes.
Therefore the question is: how to announce future backward incompatible changes to FLOSS (open source) project, so that users can prepare for them, and either change their use, or configure program to use old behavior.
Because it is OSS project, it is packaged by various distributions independently, and might be upgraded automatically without user intervention. And then backward incompatible change might mess somebodys workflow (third party scripts for example).
Avenues currently considered (and used):
- project mailing list
- project homepage
- release notes (first warning, then announcement)
- maintainer’s blog
Edit 1: This (backward incompatible) change would happen in some major release.
All changes are about either adding safeguards (refusing commands which can thoroughly confuse newbie users), or changing defaults to more sane values.
Edit 2: In the transition period the default configuration (which is meant to be changed to default refuse/deny) is changed to warn, with description how to turn of a warning, which also would protect against backward incompatibile change in default behavior.
But if it is automated system that might not help…
The project in question is Git, distributed version control system;
see Giving early warning to users at gitster’s journal (Junio C Hamano blog)
But the major version number is the primary target – people expect 1.x to 2.x transitions to cause issues, and are more careful when upgrading.
-Adam