General question about "SNAPSHOTS"

Hello,

to be honest, I still don’t quite understand how SNAPSHOTS works for Lucee.

For example, is the “5.3.9.140-SNAPSHOT” a patch that fixes bugs for the 5.3.9.133 release (comparable to a ColdFusion UPDATE), or have “experimental functions” possibly also flowed into SNAPSHOTS?

The download page says: “Snapshots can be unstable are NOT recommended for production environments.
In Server Admin “SNAPSHOTS” are called “patch”. But I understand a “patch” to be an update that fixes bugs and that can also be safely used in production environments.

Can someone please explain to me what exactly the “5.3.10.x-SNAPSHOT” are for?
Can you patch release version 5.3.9.133 with it, or are the “5.3.10.x-SNAPSHOT” intended for a later Lucee 5.3.10.x release?

Sorry, maybe these are stupid questions, but I had been using ColdFusion for 16 years and it was even strongly recommended to install all “ColdFusion update patches”. With Lucee, I’m unfortunately not at all sure how to proceed in the future.

Don’t forget to tell us about your stack!

OS: Debian 9.13 - Linux
Java Version: openjdk version “11.0.14.1+1”
Tomcat Version: 9.0.62
Lucee Version: Lucee 5.3.9.133

This is my take of “Snapshots” in Lucee.

Its a patch that corrects an issue and or enhances an item. They do not correct all issues, and may actually break somethings. Lucee being opensource, and like all opensource projects is a labor of love as much as development and discovery.

Stable versions, are just that. Everything packaged as a stable is rock solid in under most circumstances. Sure bugs happen, but thats any software :slight_smile: Usually the bugs arise from other factors involving component libraries or the OS.

I suggest testing any code, including Lucee versions before deployment.

pretty much what @Terry_Whitney said

Lucee SNAPSHOTs are just incremental builds, we rev the build number each time we make changes, it’s open source, so unlike ACF, we develop in the open.

With the SNAPSHOTs post a stable release, like say 5.3.9.133-STABLE, so for example 5.3.9.140-SNAPSHOT involve generally low risk changes, but you need to always fully test yourself any Lucee release or SNAPSHOT before putting it into production.

Lucee relies on the community to test and provide feedback on Releases, RCs and Snapshots.

We ran into some issues with 5.3.9.133-STABLE with some Ortus stuff because they were only testing stable releases with their automated CI, we are working with them to improve this.

Snapshots are great to figure out when a regression first started.

We have started work on 5.3.10.x which is currently bleeding edge, but so far quite stable.

You can always see in jira or via github commits what has changed or been added.

I’ll always post to the mailing or on CFML slack like I did with about 5.3.9.140 when we have a candidate which is considered worth testing

Got a question about a SNAPSHOT, just fire off a message here on the mailing list

3 Likes

Hello @Terry_Whitney and @Zackster

thank you for your explanations. That’s very kind of you.

I think I understand now what SNAPSHOTS ultimately stand for. In the future, I would rather test SNAPSHOTS extensively in my application before they are incorporated into the production environment.

1 Like

Just as an addition to the already good explanations.
With Lucee we talk about relese cycle.
So 5.3.8, 5.3.9 amd 5.3.10 are cycles.
First we start with Snapshots in a new cycle, until all the work is done, then we do n RC, if we feel good about it we make a release, if there are any issue encountered or there are any security updates needed, we do some SNAPSHOTS after the release and then again an RC or directly a release. A cycle can be kept open long after a new one started. And it’s normal that we work on multiple cycles at the same time. In other words a SNAPSHOT is not a release, it is more like a nightly build. In the past we actually have used a pattern like “5.3.9.140-BETA-SNAPSHOT”, but we then decided to remove the BETA in that case, because it really makes no difference.

2 Likes

Hi Michael,

since we are talking about development and that this post seems to be concluded, I ask you for some information, just out of curiosity:

  • It seems that you increase the version number with every single code change, by manually editing build.xml. In my team we increment the version number with each build/test-cycle. Is there a reason for your choice?

  • Although there are few updates, I’m passionately following the work for release 6, on its board.
    Will this choice be confirmed in subsequent releases? I think it would be useful for the community to know what you are working on. It would be a way to make the community more involved.

Thank you very much if you want to answer me.

I very much appreciate your great great great work, even on this forum.

1 Like

Short answer, we still manually rev the build version just to reduce the sheer volume of builds aka snapshots.

We have considered and still contemplating are making it automatic

As your friendly Lucee build engineer, (aka, you touched it, now you own it) we (aka I) recently improved the build process to make the first successful build, the only build uploaded as per other platforms. Previously subsequent commits without rev-ing the build version overwrote the build.

As of 5.3.9.141 and our migration to Github Actions (from travis CI) we finally have a fully integrated CI process, so a new commit which builds successfully with a new version results in a lucee downloads/admin page release, along with both forgebox/commandbox and docker builds (breathes out, oh fuck yeah)

The advantage of the current approach is simply less builds, which makes tracking down regressions (aka randomly trying previous snapshots still we find the snapshot which broke something) easier.

As the (community manager/triage nurse/how many hats do i want to wear), I’m trying to improve all our processes, and I’m pretty proud of our progress so far.

We are a small team, with basically @micstriit, @cfmitrah and @Brad_Wood (plus a heap of others) testing, triaging, creating PRs and making changes as we progress thru each sprint.

None of us work full time on Lucee and often our “real jobs” sponsor us to address problems which we encounter with our full time jobs working on stuff which uses Lucee, hence the different directions the development roadmap takes.

4 Likes

I think you may be confusing the different parts of a semantic version. Every project does versions a little different (and you’ll find a lot more variation in the Java space), but the typical 4-part java versions you see are sometimes called

Major.Minor.patch.build[-prerelease]

while others call it

Major.Minor.Micro.Patch[-prerelease]

If you’re familiar with this format

major.minor.patch[-prerelease]+buildNo

that the npm-style semver (which Ortus uses) and it’s a little different than most java projects.

I’m not entirely sure what names Lucee uses, but they treat the last number as more of a patch than a buld number. Build numbers, at least according to npm’s flavor of semantic versioning, are never meant to differentiate between different versions of the code. For example, if a given commit of the ColdBox framework is built 3 times, you may have

5.7.1+100
5.7.1+101
5.7.1+102

and while that represents three runs of the CI sever, the created artifacts could be expected to have the same code every time. I assume this is what you mean when you talk about your projects incrementing a build number.

Lucee treats the first number as a sort of “paradigm” shift version that rarely ever changes except in major changes ot the engine. (Except in Lucee 6 :laughing: ) Lucee treats the second digit as a “major” version (breaking changes increment this, etc), the 3rd number as a “minor” version (bug fixes and enhancements which will be released in a “cycle” as Micha says), and the 4th number is really treated more of a patch IMO since it’s incremented every time there is a functionality change made to the branch. (Note, they don’t use strict semantic versioning where bug fixes are a patch increment and new features are a minor increment, etc like you see in the npm space)

So Lucee doesn’t have a strict “build number” in the sense of an auto-incremented number generated in the build process regardless of whether the code changed like you see in npm modules or even Ortus’s Box modules. And Lucee treats pre-release identifiers like npm-flavor semver where the existence of a prelrease ID means a non-stable version (i.e. -snapshot, -rc, -beta, -alpha) and the lack of one means it’s stable. (Sometimes you’ll see Lucee’s marketing team confuse people by incorrectly adding prerelease identifiers to stable versions like 5.3.9.133-FINAL but that’s never the real version, it’s more of a colloquialism :slight_smile: )

Anyway, as much fun as all that stuff is, Zac pretty much answered the rest of it already while I was typing! It creates more artifacts to have a lucee jar out on sonatype for every single patch, but it’s super handy to be able to go back and test every single ticket basically that was completed since Micha generally bumps the patch every time he closes a ticket so there’s more/less one logical change per patch even though it may come in a couple different commits sometimes.

3 Likes

keep the questions coming folks, I love sharing info about all the tedious background stuff we do to make the magic happen with Lucee!

2 Likes

@Zackster Many of us look a lot into Jira and Lucees CI. To me it’s not tedious at all, its mega interesting watching the devs work. Since I’m doing that I’ve learnt tons about development, CI, cfml, Java and much more from you guys. You’ve been a great mentor to me. That positively changed my mind about open source.

Also, what I really like a lot is, that guys like @cfmitrah almost always create immediate patches for new bugs(if he can). These often don’t get merged right away, keep there open for a longer time. But we know that’s because changes always need to be carefully checked and there always are priorites. The Lucee Team is a very small team. And hey(!!!), thanks to open source we still can decide on our own to fork Lucee locally and merge that @cfmitrah s immediate patches locally and make our own Lucee.jar builds.

I’ve learnt so much in the past years from all of you guys. Always trying to give that back as contributions where and whenever I can. Hope I had more time & money to dedicate to Lucee.

Thanks to all of you!

5 Likes

I always have a headache when it talk about to the number of versions :sweat_smile:
thanks for this insight!

yes :sweat_smile:

Thanks Brad, you are always very thorough

2 Likes

This also applies to me. You learn a lot by looking at the code of others, and their approach to work.

Thanks guys :heart:

1 Like

Yeah the backlog of PRs is something we really want to address.

Alas I’m my java skills aren’t as good as my cfml skillz and I can’t code review as well as @micstriit and we have lots going on.

For 5.3.10 I’m keen to merge in existing PRs against 5.3, while @micstriit focusses on getting 6.0 ready for beta

2 Likes