Combine release for both from-file and from-tag

[DJViking]

I see a lot of changes have been done in this project since I last was here.
Good to see it still is alive and under maintenance.

I cannot see it is no longer possible to use the version in the file as a base, while incrementing from git tag.
We are using automatic versioning, so the build file contains only the base version.

Standing on RELEASE_A branch, with version 1.5.0 in build.gradle
The latest release in git is v1.5.5

Though master has the version 1.6.0 in build.gradle.
The latest release on master in git is v1.6.3.

This tools gives me the release 1.6.4. Though I am interested in getting 1.5.6.

Is this still possible, or has that feature been removed?
After the rewrite it seems gone. There was a flag to indicate to use the same version where you where standing.

"same-release", false, "for support old releases: for example 7.0.x and tag for new release 7.1.x already exist, with -same-release argument next version from 7.0.x will be returned.

What is strange is if I use -previous-release, I get the next version I want.
jx-release-version -previous-version from-tag:v1.5
This will get me the next v1.5 release, 1.5.6. PS! The latest git tag is v1.5.5, so should this not output 1.5.5?

What I really want is not needing to supply the v1.5 format. Using the base version in build.gradle would be better.

Why was this same-release feature removed? No one who needs to get a next version on an old release branch?

[vbehar]

Hi,

yes, as you found out, you can use the filter feature of the "from-tag" strategy, as explained here https://github.com/jenkins-x-plugins/jx-release-version#from-tag

so in your example - jx-release-version -previous-version from-tag:v1.5 - it will read the latest tag with the v1.5 prefix, which is v1.5.5, and then use the semantic strategy to bump the version, this is why it prints v1.5.6 at the end.

this tool is mainly made for Jenkins X needs, which promotes trunk-based development, so without long-living release branches. When rewriting the code, I tried to keep it as simple as possible, decoupling the different "phases" (reading, bumping, and writing the version). let's say that this feature was rewritten in a different way, using the filter feature. The idea is that if you're going to have release branches, you can update your release script in these branches to include the right prefix - which is easier than trying to support everyone's favorite pattern. For example in your case you want to keep the major.minor components, but maybe someone else will prefer to keep only the major component...