Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add version prefixes option to released-version goal #159

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

marquiswang
Copy link

Allow running the released-version goal with optional parameter versionPrefix, which filters the matched released versions to versions that begin with that prefix.

For example, if the released versions are 1.3.1, 1.3.2, 1.4.1, 1.4.2, and you run mvn build-helper:released-version normally, it will find version 1.4.2 as the latest released version.

This commit makes it so if you give it the parameter versionPrefix=1.3, then it will find 1.3.2 instead.

You can also pass in the versionPrefix via a property:

mvn build-helper:released-version -DreleasedVersion.versionPrefix=1.3

Allow running the released-version goal with optional parameter
versionPrefix, which filters the matched released versions to versions
that begin with that prefix.

For example, if the released versions are 1.3.1, 1.3.2, 1.4.1, 1.4.2,
and you run `mvn build-helper:released-version` normally, it will
find version 1.4.2 as the latest released version.

This commit makes it so if you give it the parameter versionPrefix=1.3,
then it will find 1.3.2 instead.

You can also pass in the versionPrefix via a property:

   mvn build-helper:released-version -DreleasedVersion.versionPrefix=1.3
@marquiswang
Copy link
Author

Fix for #154

@bmarwell
Copy link

While this fixes your goal, I wonder: Why not use maven version ranges? They are already production-proven and could do the same. E.g. -DversionRannge=[1.0,2.0) which means find the highest version conforming to 1.0 <= x < 2.0.

@marquiswang
Copy link
Author

That is a good idea. I did think that "prefixes" was an awkward way of defining things.

My only concern with version ranges is that it's moderately inconvenient for command line, since those are special characters that need escaping or quoting. Any thoughts about that?

Regardless, I think it's still superior. I will update the PR.

@marquiswang
Copy link
Author

marquiswang commented Jan 13, 2023

Actually, having implemented this, I am finding the versionRange to be an inconvenient API.

In my use case, I have a situation where my current deployed version is some version such as 1.3.2. I would like to upgrade to the latest incremental version, but I don't want to change minor (or major) versions.

Therefore, if 1.3.5 and 1.4.3 are both released versions, I want to find 1.3.5.

If the API uses version ranges, then I need to give it -DversionRange=[,1.4), which means I need to do something to figure out that 1.4 is the next minor version, or do something hacky like -DversionRange=[,1.3.999999)

Just stripping the incremental version and giving it -DversionPrefix=1.3 is a more convenient API.

Though, now that I think about it more, maybe the best API would be:

-DreferenceVersion=1.3.2 -DallowMinorUpdates=false (taking inspiration from https://www.mojohaus.org/versions/versions-maven-plugin/update-properties-mojo.html#allowMinorUpdates)

@bmarwell what do you think?

I'm imagining we adopt allowMajorUpdates, allowMinorUpdates, allowIncrementalUpdates, (and maybe allowDowngrade and allowSnapshots) from the versions plugin, and only apply them if the referenceVersion is set.

Though... this requires depending on the versions plugin, or at least versions-common, which I'm not sure we want to do.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants