Hey Gang,
Can someone please let me the know difference(s) between
the 5.3.9 and 5.3.10 branches.
Always - Thanks!
Gavin.
Each release has a changelog, you have to check both releases with 5.3.10
1 Like
Not really all that helpful…
There are no release notes that I can find for 5.3.10
There isn’t anything that I can find in GIT or the website that says -
5.3.10 is different to 5.3.9 - because of xxxx.
You can use a filter in Jira to see what tickets were deployed between any 2 given versions:
Perhaps I haven’t explained myself properly - or perhaps there is no answer???
But to my way of thinking…
for 5.3.9.xxx → 5.3.9.yyy changes - incremental changes - no fanfare needed.
5.3.9.xxx to 5.3.10.xxxx - is there a purpose for a change of branch from 9 to 10.
Lets assume there is a new 5.8 branch created with code changes…
How is that different to simply making a change “somewhere” in the 5.3 branch?
Are there prerequisites for updating from a 5.3. branch of Lucee to a 5.4 branch?
Are there prerequisites for 5.3.9 to 5.3.10?
Is it - Underlying library changes?
or is it “JUST” a new branch for the hell of it?
We thought the numbers were getting pretty high on the 5.3.9 branch so we made a 5.3.10 branch?
If 5.3.10 is a superseded version of 5.3.9 - why do fixes get ported into 5.3.9, still?
I find the Lucee re;ase process very confusing.
1 Like
Lucee is open source, and a product of love like all open source projects.
Maybe take up the “change.log” mantle, and help write code or document the changes or even sponsor it. As many times the releases are bug fixes in response to someone on this forum that generally are stable as is.
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.
3 Likes
@Terry_Whitney
Sorry? What are you talking about?
How does asking for help with the way the versioning is done - equate with “Put your hand in your pocket?”
AND - I am already a subscriber - not that it should matter, at all, to the question I asked.
If you do not like the way an open-source project is doing something,
Roll up your sleeves and contribute to how you would want it to be done.
Got it…
So, there is not necessarily a backport of everything between master/head and the previous versions…
And the DOT releases are maintained for the comfort level of end-users.
I think this is where I had it muddled - in that I couldn’t understand how 5.3.10 - could be the superseded version of 5.3.9 AND work was still being attributed to the 5.3.9 branch. To my mind at the time of writing the original post - if .10 was the latest of 5.3 - then “surely” - .9 should be archived / abandoned.
Thanks - appreciate the help.
1 Like
@bdw429s in my opinion your description of the versioning is something that should/must be moved to the docs. Can I copy/paste it and add it somewhere in a PR?
2 Likes
Certainly!