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
while others call it
If you’re familiar with this format
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
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 ) 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.
-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
188.8.131.52-FINAL but that’s never the real version, it’s more of a colloquialism )
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.