Find next release version globally

[jwermuth]

Thanks for a nice plugin 8)

I have a use case, where I need to consider versions in all branches and find the largest amongst them all. Given the git tree below:

*   9c01bbb (origin/master, origin/HEAD) message
|\  
* | a71e0c4 (HEAD -> master, tag: a-0.4.14) message
| | * 3324005 (origin/feature/nice-hat) message
| | * 9afa1f5 (HEAD -> master, tag: a-0.4.15) message
|

with the current functionality of axion, when i release at master, i get a conflict, because the next version seen from master perspective will be 0.4.15 which is already a tag.

Does anyone see a way to configure the current axion to consider all tags when selecting the next version ?
I would be happy to code the feature, but I would like some directions so I implement the functionality in the right place, seen from an architectural perspective.

[adamdubiel]

Hi :) Current implementation works on current branch only on purpose. I never considered doing all-branch scan and so don't know if its possible.

However if you would like to explore this direction, I would start with:

• finding git command that would print all the tags that you need
• finding how to implement / call the same command in JGit
• note: it might not work on CI/CD, since they try to fetch as little data as possible
• implementing feature switch
• implementing logic alongside GitRepository *position methods

If you find a way to achieve it I will help you with proper implementation in GitRepository.

[jwermuth]

Thanks. I am working on it. Found some of the way through. Wrote a little code and a test (which is currecntly red, as expected).

One thing - it seems the options to:
1 useHighestVersion
2 not useHighestVersion (default)
and the new i am suggesting
3 useGlobalVersion
are mutually excluding, meaning that they do not make sense in combination. Using the current settings model (a boolean, useHighestVersion), it is only possible to select one of the 2 existing modes (1 and 2), effectively making it impossible to configure both.

If/when i introduce a new boolean (e.g. useGlobalVersion), it will be possible to set both, useHighestVersion=false and useGlobalVersion=true, which does not make sense. If you use global version, you consider ALL tags, which is the point.
So, introducing useGlobalVersion is backwards compatible, but makes it possible to set both useHighestVersion to either true or false, and set the new useGlobalVersion which does not make sense.
Adding a selector [useHighestVersion|useFirstVerstion|useGlobalVersion] would be more correct, but would not be backwards compatible.

I suggest adding the useGlobalVersion and make it clear in the description what is going on. Later, when you bump the major version (signalling breaking backwards compatibility) you/I/someone could consider replacing the 2 booleans (useHighestVersion and useGlobalVersion) with a selector.
Does that seem reasonable to you @adamdubiel

[jwermuth]

Hi @adamdubiel. I wrote some code in my clone, on this branch. And a couple of tests. It seems to be working.

You are welcome to have a look and comment ?

I am still missing

1. add some more tests
2. adding integration tests
3. refactor the handling of Version Reading Strategies

Once that is done, and if you do not have further comments, Ill make a PR.

PS: You are welcome to assign me to this issue - I am working on it.

[jwermuth]

Implemented and created pull request #342
@adamdubiel do you have time to look at it, or is there someone else who has write access to the repo

[adamdubiel]

Hi, I will take a look at the PR :)

[jwermuth]

During final testing of the additions i made to the plugin, I created a seperate repository/project that helped me test the jar built in axion-release-plugin. The repo is here.
The idea is to:

1. build the plugin jar,
2. copy it to 'axion-release-plugin-test/libs' and then you are able to
3. take the plugin for a manual test spin.

Perhaps its of use to someone else...

[big-andy-coates]

Would people mind if I asked a question on this, given there is a PR waiting to be merged...

The use-case, as given in the description, seems to be building releases of feature branches. I'd say there is a strong argument that this is not to be encouraged, and hence should not be supported.

Releasing off of a feature branch introduces a large risk of regressions in releases. Consider two features being developed in parallel, both becoming ready for release around the same time. The first branch is released.. yay! 🚀 and then hopefully merged back into the main branch. Then the second feature branch is release.. but maybe this is done without first merging changes from the main branch, or maybe the first feature branch wasn't yet merged into the main branch... now your second release doesn't include the code from the first feature branch... regression! boo! 😢 .

This is kind of a known anti-pattern.

Merging feature branches into the main branch and releasing from there means you're always releasing new features and fixes on top of old.

Or maybe I'm just not understanding the use case fully....?

If I'm not, then IMHO supporting this cross-branch searching for the highest version number is encouraging bad patterns, and so shouldn't be supported.

[grhawk]

What if you add a "-SNAPSHOT" at the end of all versions that are not master/main?

So you would have:

branch-1 -> v1.1.0-SNAPSHOT
branch-2 -> v1.1.1-SNAPSHOT (even if this does not contain the v1.1.0)
main -> v1.1.2 (contains both)

Would this be an anti-pattern as well?

What would be the right way of testing two different branches while developing? (I am genuinely looking for a decent way :))

[big-andy-coates]

That's certainly not semantic versioning, which is what most people use these days.

With semantic versioning, v1.1.1-SNAPSHOT should include all the features & fixes released in v1.1.0, (and hence generally in v1.1.0-SNAPSHOT).

While releasing standard semantically versioned releases from feature branches is bad practice, you could release using non-semantic versioning, including, for example, the branch name into the version number.

Giving you:

(main branch has next version v1.1.0)
branch-1 -> v1.1.0-branch-1-SNAPSHOT
branch-2 -> v1.1.0-branch-2-SNAPSHOT (even if this does not contain the v1.1.0)
main -> v1.1.0-SNAPSHOT (contains both if/when they are merged back to main)

[grhawk]

Thank you very much for the explanation...

In my case, we are using Concourse for the deployment and, sometimes, we need to deploy directly from branches. Mostly for testing purposes.

The problem with Concourse and its maven-repo "resource" is that it only supports semantic versioning. This means that we cannot follow your example and, as of now, we manually create a new version (which is exactly following the antipattern).

I completely understand that the problem is with the "maven-repo" resource of Concourse. However, I find it easier to help in implementing such a feature here because the "concourse resource" is in Go.

Another point could be that... even though this is an anti-pattern, this would be a feature that the user should enable and not something that the user is obliged to use. I think implementing the feature and documenting it as an anti-pattern would be more useful and instructive than not having the feature at all.

[big-andy-coates]

Thank you very much for the explanation...

In my case, we are using Concourse for the deployment and, sometimes, we need to deploy directly from branches. Mostly for testing purposes.

The problem with Concourse and its maven-repo "resource" is that it only supports semantic versioning. This means that we cannot follow your example and, as of now, we manually create a new version (which is exactly following the antipattern).

I completely understand that the problem is with the "maven-repo" resource of Concourse. However, I find it easier to help in implementing such a feature here because the "concourse resource" is in Go.

Another point could be that... even though this is an anti-pattern, this would be a feature that the user should enable and not something that the user is obliged to use. I think implementing the feature and documenting it as an anti-pattern would be more useful and instructive than not having the feature at all.

Your point that this isn't something that's on by default makes sense. However, this still feels like adding functionality here, which needs to be maintained, that is a work around to an issue somewhere else. The best solution, as you've noted, is to fix the issue in Concourse, so it allows more free-form versioning.

An alternative, which may work for you without upstream changes, might be to include the branch name in the artefact name. This would work with Concourse. Though maybe you've already considered this and discarded it for other reasons.

Ultimately, if this feature is to be implemented, then I think calling out in the documentation that this is an anti-pattern is better than nothing.