First off, thank you for responding promptly to the recent security issue and releasing a new stable version containing the fix.
Some folks were annoyed that in order to get the security fix, they had to take an entire new release with a lot of additional functionality, requiring they do a lot more testing before putting that release introduction production. Below I make a proposal for easing that problem.
Railo and Lucee have long followed a variant of Semantic Versioning that has enabled a very smooth, automated update process. It has always been the case that version numbers are strictly monotonically increasing and that releases are strictly cumulative, i.e., version x.y.z.(nnn+1)
always includes all the functionality of version x.y.z.nnn
.
The current process of always pushing new versions out through the dev provider, then promoting some of those to the preview provider, and then promoting some of those to stable has generally worked well, but it creates a problem when a small, high-priority fix such as a security patch is needed.
Consider what happened with this latest release: 4.5.1.000
was the previous stable release, and 4.5.1.001
thru 4.5.1.021
had already been pushed out through the dev provider, so when the security patch was made, there was “no choice” but to add it to 4.5.1.022
and push it out through the same channels: there was no space in the number sequence to push a security patch to 4.5.1.000
that would have preserved semver and cumulative releases.
Proposal
When any version is promoted to the stable provider, immediately reset the next dev version to increase the minor version number (with the patch number set to 000
). This would ensure that if version x.y.z.nnn
is stable, the next dev stream would be x.y.(z+1).000
onward. This would always leave space for high-priority security patches to be applied in isolation to the stable version (as x.y.z.(nnn+1)
etc).
Proposal Applied
For the case in hand, once 4.5.1.000
was declared stable, the next dev version should have been 4.5.2.000
and it could have been rev’d up to 4.5.2.021
as before, but when the security patch came in, it could have been made available as 4.5.1.001
on the stable provider, allowing users to “safely” update without needing to pick up a lot of other functionality, whilst still preserving the purely cumulative native of releases on each provider stream. So we would have had 4.5.2.022
on dev containing the security patch, and 4.5.1.001
on stable containing the security patch, reducing the risk for users who want to maintain a stable-only production server.
You could then have promoted 4.5.2.022
to preview for extended testing and ultimately to stable (at which point dev would change to 4.5.3.000
).
Now, of course, if you’d released 4.5.1.021
as the new stable release a few weeks back as indicated in your blog post, and then 4.5.1.022
had come out containing only the security patch in addition, folks would still have had to accept a block of functionality in order to update from 4.5.1.000
but it’s reasonable to argue that 4.5.1.021
had been out as stable for two weeks and they had time to start testing. Still not ideal, but better than what actually happened, IMO.
Anyway, I hope you will consider bumping the minor version in future every time you release a new stable version, so that you can leave space in the version numbers for high-priority patches. Thank you.