Hi,
Consider, for example
Lucee 5.3.10.97 Stable (Nov 25, 2022)
Lucee 5.3.10.97-SNAPSHOT (Nov 25, 2022)
What is the difference, if any, between Stable and Snapshot Lucee versions that have the same semantic version number?
@Zackster : why?
If there is no difference, then that can be confusing. Lucee documentation says,
Stable “Releases are ready for production environments.”
“Snapshots are generated automatically with every push to the repository. Snapshots can be unstable are NOT recommended for production environments.”
Therefore, according to the documentation,
Lucee 5.3.10.97 Stable (Nov 25, 2022) is ready for production environments. Whereas Lucee 5.3.10.97-SNAPSHOT (Nov 25, 2022) can be unstable and is NOT recommended for production environments.
it’s pretty clear, 5.3.10.97 was first published as a a snapshot via CI and then was (re) published as a stable release?
2 Likes
Every code change to Lucee results in the build number being incremented (manually by Micha).
Every commit to Lucee results in a build artifact being generated (if the tests pass) which always has a -SNAPSHOT prerelease identifier.
When Lucee reaches a stable point and Micha wishes to make the last build be a “stable” build, he runs the build one final time for the stable release (without incrementing any build numbers, because no code has changed!) which results in a build artifact bearing the same version but without the -SNAPSHOT prerelease identifier.
This means that for every stable build, there will have been a snapshot build with the same code and version. This is just how the process works.
- Every code change gets a unique version
- Every code change gets a snapshot build
- Code changes that represent a stable point in the software which is ready to release get a stable build as well
1 Like
Thank you for your explanations. They only emphasize the point I wish to raise.
Namely, if
Lucee 5.3.10.97 Stable (Nov 25, 2022)
and
Lucee 5.3.10.97-SNAPSHOT (Nov 25, 2022)
are the same then, for this particular case, the following Lucee documentation has a contradiction:
“can be unstable” vs a release marked stable, i think it’s pretty easy to comprehend
1 Like
“Stable” vs “can be unstable” doesn’t quite capture the contradiction. The contradiction is “ready for production environments” vs “NOT recommended for production environments”
I think you’re being uneccessarily pedantic. Consider this equivalent series of statements.
- Some wild mushrooms may be safe to eat, but others can be poisonous to humans. Therefore, any given mushroom you have found in the woods should be considered potentially unsafe.
- Mushrooms which have been evaluated by a mycologists (mushroom identification expert) and found to be not poisonous are considered safe to eat.
These statements act as a filter generating a subset of the previous set. The first statement applies to all mushrooms that exist. The second statement creates a subset of the first set-- the mushrooms which have undergone a verification process, thus allowing us to apply specific characteristics to them-- namely being safe for human consumption.
You will note that all the mushrooms described in bullet two are ALSO PRESENT AND DESCRIBED in bullet 1. This is not a contradiction. It is a contextual observation. Mushrooms which have not been vetted, may be safe, but you should assume the worse. Mushrooms which have been vetted are now known to be safe.
Also note, these two observations are not being made at the same time! The first is applied the moment you spot an unknown mushroom. The second is made at a later point in time once testing has been performed on the same mushroom and that determination SUPERCEDES the previous “safe” assumptions.
The same is true of releases.
- A random bug fix/commit/version may or may not be stable. Therefore, you should assume they are not safe for production usage.
- A specific version of Lucee which has been tested and passed a verification cycle can now be considered production-ready.
These are not contradictions. All versions start in the first bullet point and only a few versions are certified as described in the second bullet point.
1 Like
To all what the others already said… This all is a standard workflow of building in CI . Many other software companies and architects follow the same versioning and naming convention (nightly builds/bleeding edge/snapshots, release candidates and stable releases).
For open source devs its always very clean to see the state of commit history of a software build simply by looking at the version. The version number is just a time pointer to the commit history. That way we can clearly see what have been deployed to those builds by just checking the offical issue tracker and the github commit history - no matter if its a RC, a snapshot or a stable release. The build time in development is stated by the one and only unique version number.
I undestand that this may be new to the ones not familiar to agile development and CI workflow.
However, I’ll add this information to the docs as a contribuition soon, so it gets clearer to everyone.
Please also see this so post from another software arquitect, who tells about his dev workflow that is quite similar in a bunch of CI workflows:
Your explanations make sense. Nevertheless, they only emphasize the possible contradiction in the Lucee documentation on Snapshots, namely:
“Snapshots … are NOT recommended for production environments.”
The examples I gave,
- Lucee 5.3.10.97 Stable (Nov 25, 2022)
and
- Lucee 5.3.10.97-SNAPSHOT (Nov 25, 2022)
imply that a Snapshot version may be used in production. This is not mere pedantry. It is a contradiction of the emphatic “NOT” in the documentation.
It is not accidental that your explanations contain qualifying words such as “may”, “may not” and “potentially”. If a snapshot version may be used in production, then the phrase
“Snapshots … are NOT recommended for production environments.”
should be corrected to something like
“Snapshots … may not be suitable for production environments.”
I’m not in favor of this wording, because it doesn’t tell when it is suitable and when it is NOT suitable for production. It will lead to more confusion and question posts here in the community forum about “how to identify a ‘stable’ snapshot suitable for production”. Snapshots are not meant for production, so please use the stable version because that is the recommended version…Just like @bdw429s already said… Just get the “mushroom” that has been carefully handpicked for you to be used in production.
If you really want to use a snapshot in production, please take a look at the commit history and reference it to the Lucee Devs working progress on the offical issue tracker, and you’ll know which snapshot is suitable for your production server.
Of course, I totally agree that right now the descriptions aren’t the best, and I’m sure it will be enhanced in future.
No problem. As long as the Lucee documentation is changed so that it is as clear as the mushroom example.
Another suggestion:
“Snapshots are NOT recommended for production environments, with the exception of Snapshot versions that are also identified as stable releases. The latter are course ready for production environments.”
1 Like
@BK_BK ,
I take onboard, everything you’re saying.
I am not a fan of the Lucee terminology / versioning, either.
Being told that “snapshot XXX” is Okay for production in “this” instance of the snapshot, because all it does is address “a” regression found since the latest “release” - but then being contradicted, by…
STABLE is ready for production / others are not…
Just rubs me the wrong way.
I don’t, ever, like to use anything NOT marked as “release / stable / etc” for a production scenario.
That being said,
Lucee, “is what it is” and doing their best with the resources that they have, in a manner that suits the people, that do all the work.
If someone that JUST reads the docs, only - then using a “stable” release will “practically” always be the right way to go. If clarification is required - then just like you have - they can get in contact via the forums / github and get the best advice at the time of asking.
Personally I’d rather see a “hotfix” “tag” used for a bundle that comes after a “release”, to correct a bug only.
IMHO, that would solve a lot of the questions that come up here in the forums about Lucee versioning.
Lastly,
And please this isn’t an attack on you - I am guilty of exactly the same thing - but for anyone that might end up here via a google search…
Let us ALL not forget that Lucee is a “free to use” AND “open-source” software.
They do : do an awesome job of with their professionalism and support of their product.
But it is NOT a commercial entity.
(again - not “AT” you - just generally)
I think it is unfair to expect a “I paid 10k to use this - give me some support you’re like your personal
paycheck depends on it”, level of support from volunteers.
The Lucee team are, sincerely, VERY OPEN to code and documentation improvements.
A Pull Request is always graciously and gratefully received.
1 Like
Good one! Hotfix would be great!
However, the snapshots that fixes regression of stable releases have always been merged and published directly as a following “stable release”. Just take a look at the stable releases 5.3.9.xxx: All snapshots with the fixes have been pushed to a latest release version. You really won’t need to watchout for hotfixes or identify what snapshots are treated as such, because they are also merged to the latest stable releases. One problem are those builds that need some time to be built, because they need further action, like installers/dockers.
I agree - but it removes the “doubt / misunderstanding”
And if there is ever a lag in the “release” making it out the door - the intention, in my mind is muich clearer with “hotfix”.
2 Likes