Lucee 5.3.9 vs 5.3.10

Lol, I think you’re overthinking this pretty hard. Lucee follows a pretty standard release process using (mostly) semantic versioning. Their version numbers are built like this

major.minor.patch.build

where

  • major is a paradigm shifting release where major overhauls happen
  • minor releases are when breaking changes are made and happen once a year or so
  • patch releases represent a stable collection of bug fixes and enhancements
  • builds represent a single commit/build fixing one issue or adding one feature

Now, just like how trains don’t simply drive past the station and people have to decide which car to aim for and just jump for it, trains come to a stop periodically and say, “this is a good time to come aboard”. Lucee, like virtually every other software out there, does this as well with their patch releases. Every few months, they wrap up a collection of fixes and enhancements which are stable and release them as a good “jumping on” point to update your Lucee server. Otherwise, it would just be an endless stream of tiny releases every few days!

So, 5.3.9 was a pause where Lucee cut a nice stable release of their work to date. And then, a few months later, 5.3.10 was another pause in the tracks where they cut another nice stable release of their work to date. So, I guess the explanation of why that release exists is… because they wanted it to??? I mean, they have to release the latest fixes and enhancements at some point, right? So, that’s what they did.

5.4 is a minor bump because it will be a breaking change. For security reasons, Hibernate will receive a major version bump and several outdated extensions will be dropped from the core distribution.

If 5.3.10 is a superseded version of 5.3.9 - why do fixes get ported into 5.3.9, still?

Well, firstly, upgrading can be a scary process for companies who have a lot of testing to do and have gotten bit by regressions. Therefore, if there is a fix that is security-minded or fixes a rather nasty bug, Lucee reserves the right to also cut a new build of their previous patch release with those important fixes. That gives companies who may be afraid of a whole new release with dozens of tickets a way to get those few important fixes with much less risk. This is a pretty common practice in software.

5 Likes