You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The next development version is computed by increment of one, for either the buildNumber when present or the patch version even when those one are set to zero.
The current logic does not allow us to use the patch version for hotfixes only.
For example, given a current development version 6.144.0-SNAPSHOT, if the logic is to increment the patch version, at release time, the plugin will propose 6.144.1-SNAPSHOT but I need 6.145.0-SNAPSHOT and I will have to manually update the next development version at every single release.
Now, if we change the logic to increment only when it is not zero, I only need to change the next development version when a major change is required, the rest of the time the desired version part will be incremented automatically.
The new logic would propose by default, given an upcoming release version, a next development version :
Everything works as before except for when the lowest version part is zero.
The last case with the current code proposes a next version that is the same as the release version.
We will use that now on in my company, I have a patch if all that make sense for you.
The code change uses the build-helper-maven-plugin VersionInformation logic to keep the code clean and readable, it also allows generalizing that logic to major.minor.patch-buildNumber and there are the unit tests.
The text was updated successfully, but these errors were encountered:
At the end I kept the default behavior and gave the possibility to use org.jfrog.artifactory.releaseManagement.nextDevelopmentVersionStrategy to be either not set, have a "default" or "ignore_zeros" values and wrong value to use "default", see the PR #67
Hi there,
The next development version is computed by increment of one, for either the buildNumber when present or the patch version even when those one are set to zero.
The current logic does not allow us to use the patch version for hotfixes only.
For example, given a current development version 6.144.0-SNAPSHOT, if the logic is to increment the patch version, at release time, the plugin will propose 6.144.1-SNAPSHOT but I need 6.145.0-SNAPSHOT and I will have to manually update the next development version at every single release.
Now, if we change the logic to increment only when it is not zero, I only need to change the next development version when a major change is required, the rest of the time the desired version part will be incremented automatically.
The new logic would propose by default, given an upcoming release version, a next development version :
6.1.0-22 -> 6.1.0-23-SNAPSHOT
6.0.1 -> 6.0.2-SNAPSHOT
6.1.0 -> 6.2.0-SNAPSHOT
6.1 -> 6.2.0-SNAPSHOT
Everything works as before except for when the lowest version part is zero.
The last case with the current code proposes a next version that is the same as the release version.
We will use that now on in my company, I have a patch if all that make sense for you.
The code change uses the build-helper-maven-plugin VersionInformation logic to keep the code clean and readable, it also allows generalizing that logic to major.minor.patch-buildNumber and there are the unit tests.
The text was updated successfully, but these errors were encountered: