A normal version number MUST take the form X.Y.Z where X, Y, and Z are non-negative integers, and MUST NOT contain leading zeroes. X is the major version, Y is the minor version, and Z is the patch version.
but I often encounter modules which do not include all 3 parts of the proposed major.minor.maintenance style.
Many smaller modules get their bugs fixed in minor versions. This is, in part, because maintenance versioning works best when you maintain minor version branches (like 1.2.x), which is more trouble than itâs worth for many modules. Assuming â.0â when the maintenance version is missing is okay. When/if a maintenance version is needed, the third spot is still there for you.
Itâs the modules that have adopted version numbering like 1.2.3.4 that Iâd like to see evolve to the major.minor.maintenance pattern.
Seems like we agree that also modules should follow semver. I think the maintenance portion should also be included even if its 0 since thatâs what semver says.
FYI, Iâve started releasing modules using semantic versioning, see coreapps and owa. More modules can be released that way with the imminent Reference Application 2.5 release.
I think you cant really answer this question now. I mean if there is a bug that gets reported after this release you will fix it and probably release the fix right away in 4.4.1.
But if there is no bug and you add a small new feature (backwards compatible) you will probably just go for 4.5.0
I think it shouldnt be set in stone that for small modules we always bump up the minor version in between releases.
I agree with tentatively bumping the minor version when setting the next snapshot version (ie, the 4.5.0-SNAPSHOT option). This is what we do on the OpenHMIS modules as we donât usually know if the next release will be a big or small one. We decide what the actual version number will be just before releasing, only increasing the minor version if there is some non-breaking new functionality.
However, this does seem like an internal team development practice that shouldnât have too much of an impact on others given that outside projects should not depend on SNAPSHOT versions of dependencies they donât maintain.
Right, more a development/style question than anything else⊠Actually, I went with the 4.4.1-SNAPSHOT for the following reason:
In our build pipeline we are using the âversionsâ plugin to automatically increase our version numbers. For many modules in our pipeline, we only use released versions, but in some cases we rely on snapshots. If we were running on 4.5.0-SNAPSHOT and then did a 4.4.1 release, assumedly the âversionsâ plugin would not consider this a âlaterâ release.
When you release a module, the next version should be a minor version increment, both in Maven and JIRA.
Details
The default assumption should be that the next release will be a minor release, not a maintenance release. If someone wants to do a bugfix-only release, they can create an extra fixVersion at the time. Thinking historically, we have almost never done maintenance releases of modules.
E.g. when youâre releasing REST 2.18.0, the next version should be 2.19.0, so (1) youâd only create a JIRA version for 2.19.0, and (2) youâd set the working version to 2.19.0-SNAPSHOT in maven.
The maven release plugin does not do this by default (e.g. when you release 2.18.0 it defaults to 2.18.1-SNAPSHOT), but maybe we can get around it with this flag (I havenât checked how), or in our bamboo release plans.
The projectVersionPolicyId appears to not yet be released: https://issues.apache.org/jira/browse/MRELEASE-979
Iâm not even sure when 3.0.0 is going to happen, and the implementation of that is a little bit tricky too.
So what I did instead was https://github.com/openmrs/openmrs-contrib-bamboo/pull/3
It enforces semver to releases. Also, if you donât override the development version variable, and the release ends with â.0â, it will apply the rule above.
Is that OK to enforce semver to every release using that script? Without that, the script will need to be a little smarter.
I vote +1 on enforcing semver for all modules released via bamboo.
Before I had to include the â-SNAPSHOTâ in the development version variable. I guess with this script that wonât happen anymore? Is there a way to document this with a comment thatâs visible on the screen where you override plan variables?
Hum, no, sorry, I cannot really modify that screen when overriding plan variables. We have the plan description below the plan name, but thatâs about it.
I can always print things on the logs, but reality is that itâs a little bit too late and also it not so visible.
@cintiadr, I just released the reportingrest module (bamboo logs). I only specified the release version of 1.8.0. It automatically set the dev version to 1.8.1-SNAPSHOT, but I was expecting you had made it go to 1.9.0-SNAPSHOT. Is that right?
