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.
5 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.
2 Likes
@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!
@Terry_Whitney
Pretty sure that I do not have the appropriate access to the Lucee Repository / build chain - so that I can “just” go and change it to something that feels comfortable to me.
Asking for clarification / a better understanding… even wholly disagreeing… doesn’t equate to “change it”.
I really wonder - what are you talking about at times!
Because I do roll my sleeves up.
I test ALL the RCs (and oftentimes the snapshots, too) with my code and report any issues.
I offer my assistance where I can, when I can.
I have corrected a bug in the Windows Installer.
I have corrected errors and submitted readability changes to the documentation.
I ask questions in public forums - and have no problem asking the “stupid” questions - in a public forum - when I feel perhaps that someone wants to ask “A” but doesn’t want to look like an idiot - I give zero currency to people thinking that I may not be the sharpest tool in the shed.
After all - I know that I am not.
I answer questions that I can in the public forum.
AND I PAY to use Lucee. Nothing outstanding - but it is ongoing.
Telling me to contribute to the open source project, to a post that is seeking clarification on a fundamental cornerstone of the project is just non-sensical.
2 Likes
I am sorry you do not like my comment(S).
You didn’t like “documentation” or how the project is documented, my comment though stands.
Your contribution is feedback, you don’t like how the project is documented.
My comment to the whole process is “DO MORE”.
You can comment on code, you could even maybe submit a github request to make comments auto chained into the build process as semi-informal change log to better write an actual change log.
every stable release has a detailed changelog posted and tagged in the releases category
1 Like
This was still in my to do list. Finally added it 
with Add version numbering to the download and installing docs by andreasRu · Pull Request #1370 · lucee/lucee-docs · GitHub
2 Likes
I actually found your original question, completely reasonable. It’s strange that some people get so triggered and see everything as a criticism. 
As always, a first class explanation from @bdw429s
4 Likes
Iny opinion criticism is always more than welcome. Every criticism tells us that there is need to talk and we need - at least - try to make things even better and get the best out of it. If people don’t crticize, we may keep stuck forever and stop trying new things.
2 Likes
Hi Andreas. I appreciate your comment about criticism, being welcome, but I would only say that is helpful, if it is constructive criticism. Telling us to contribute, when we are trying to resolve a versioning issue, isn’t particularly constructive, in my opinion.
But I don’t want to cause yet another argument, about the definition of constructive criticism. So, I will leave it, at that. 
4 Likes
I have to agree with the OP re the confusion here. It isn’t {major}.{minor}.{patch}.{buildnumber} - because we have patches releases with lots of different builds. So when that number changes, it feels like that might be a significant change.
I know that not all things should be the same - and semantic versioning is just one choice of many. But it should be clear from releases notes, etc. what a bump would mean. It really isn’t right now.
I’d personally prefer changing the release numbering so that you never get more than one 5.4.2 release (though the number might include a build number), and never more than one 5.4.3, etc. Changing the presentation to 5.4.3+749 also would indicate that the old system of multiple releases for a single patch version is no longer used.
(talking to @Zackster and apparently this simplification of single patch releases is what is being aimed for).
2 Likes