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
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.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.
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
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
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.