Code cleanup breaks binary compatibility
I'm working on a project that is being used by a number of people I don't know. We did a pretty good job with the CheckStyle warning, and the point is that it will be low because it will work without breaking binary compatibility.
Most of the remaining warnings are caused by (public static final) constants omitting the last keyword. Naming constants makes it clear that the developer wanted them to be read-only, but they just didn't have a definitive definition on them.
Unless the developer wrote some pretty awful code that used this oversight, their code won't break if we add them.
Currently the version number is 1.2.1. You would apply that change and go to 2.0, or apply and collapse it as 1.3. It seems like a rather small change requires a full 2.0.
What should I do?
source to share
I'm sure you already know this, but I suspect it should go down to a "is it safe / easy / no problem" update?
- Point releases are considered safe and routine. They should consist entirely of bug fixes in some projects. Other projects will include new features if they are unlikely to cause problems.
- New versions of major versions contain evolutionary changes that may require adaptation
- New major versions of x.0 version are considered very suspicious for sophisticated users :-)
I think it also depends on how close you are to the next version of the main release. If it's soon, don't risk a problematic point release. You can always do a safe point release and an alpha release, but it might be strange if the next major release is in the future ...
source to share
In my opinion, such changes that could break binary compatibility should be put on hold until a major version is released. That is, your question should not be "What version number should I use", but rather "When should I make these changes".
If you are fully committed to binary compatibility, you should defer these changes until a release that contains significant improvements to justify the cost of the upgrades. For example, the KDE project imposes binary compatibility requirements for major releases. This means that any improvements over the lifetime of this version cannot break applications compiled against older versions. Therefore, developers looking to clean up code should wait for the next major release.
Once you are ready to release the main release with all of its new new features, make whatever binary compatibility changes you deem necessary, in which case if something breaks it is not that surprising.
If you want to be smart, you can implement a pre-processor and compile the code twice, once with the final and once without. This can be used as a stepping stone to the true finale, but the cost of maintenance is high nonetheless.
source to share
I say break them. If you are a mutant static then you must know what you are doing wrong. However, you might want to split it into a different version so that clients have a chance (whether they accept it or not) for a smooth upgrade rather than panicking because they need some other unrelated fix.
source to share
Unless the developer wrote some pretty awful code that used this oversight, their code won't break if we add them.
How to subclass previously non-final classes that will no longer work?
I think it should be 2.0 and that you should support 1.x series support
Also, here's an interesting video about the API: " How to Build a Good API and Why It Matters " by the creator of Joshua Bloch, so the core libraries in Java are still working on Google
source to share