I've been discussing it in the Github ticket but I wanted to bring it here because that's where our regulars are.
The TL;DR is that we're going to be making the following changes in OgreNext:
-
Next Ogre Next release will be 3.0 instead of 2.4
-
Follow a modified version of Semantic Versioning (MAJOR.MINOR.PATCH) where:
-
PATCH can only be bumped as long as ABI compatibility remains 100%.
-
MINOR bumps as long as API compatibility stays >= 95% for all components and plugins, according to abi-compliance-checker. Measured against MAJOR.0.0
-
This is not strictly in compliance to SemVer, but stays close to its spirit
-
-
MAJOR bumps when API compatibility is < 95%. Although MAJOR can be bumped even if compat >= 95% at the dev's discretion.
-
As a result the following would be achieved:
-
Patch +1 bumps can be release for hot fixes. Bugs that are easy to fix without breaking ABI and deploy everywhere.
-
Minor +1 tells our users upgrading is painless. A recompilation is necessary. Build errors may appear, but they should be very quick & easy to fix.
Projects like Ignition which have strong ABI requirements can leverage whether to move to Minor+1 if they have to when a certain bugfix is too important and can't be done without breaking OgreNext's ABI.
Main focus for minor bumps will be for fixing bugs that can't be or are too hard to fix without breaking ABI. -
Major +1 tells our users to prepare for larger upgrading efforts. Although not necessarily too large if we release more often.
This is similar to Ogre's recent version change to SemVer where Ogre jumped from 1.12.x to 13.x; although Paroj is following SemVer rules strictly (i.e. MINOR bump +1 when API compatibility >= 95% is not really SemVer).
That made the most sense since bumping 1.12 -> 2.0 would've caused massive amounts of confussion.
The only question remains what happens when we start development of a new version after release. i.e. after releasing OgreNext 3.0, should master be 4.0 or 3.1?
I've been giving it a hard thought and:
-
Developing master as 3.1 is risky becaues we will start accumulating API incompatibilities, giving us less manouverability if we need to fix 3.0 by breaking ABI while still being API compatible.
-
But if when the time arrives to make a new release and API compat is still very high (e.g. >= 98%?) it would make sense to release master as 3.1 instead of 4.0
After much consideration I believe that:
-
By default master should always bump MAJOR, i.e. if we release OgreNext 3.0, master should be 4.0
-
When the time comes to release, we can always change this and branch to 3.1
At our discretion, we reserve the right to still release it as 4.0, instead of 3.1
The rationale behind this, is that there are releases where new features are introduced that may be unstable and will need a lot of testing. Therefore a lot of fixes are anticipated and reserving 3.1 makes sense
As an example, this is what happened with OgreNext 2.2, where we released 2.2.0 through 2.2.6 because there was a major texture refactor, which required a lot of minor tweaking and fixing.
Other causes may be a paying client anticipating they'll need several minor features or fixes
Feedback?
