Possibility to set versionRange in maven plugin

[tommy-bo]

We use a custom versioning mechanism in maven to automatically generate semantic versions. This mechanism keeps the development version at X-SNAPSHOT while releases of the component will be X.0.0, X.1.0, X.2.0 and so on. With the current solution the versionRangeWithProjectVersion is read only as "(,X-SNAPSHOT)" but we would like to be able to configure this range to something like "(X,)" so that previous release could be resolved automatically.

[twogee]

Would #172 solve that? It generates the range automatically.

[tommy-bo]

Not sure, we're handling versions in a special way so that a pom at version X-SNAPSHOT will be released to X.Y.0 and a pom at version X.Y-SNAPSHOT will be released to X.Y.Z. During development the version will just be featurename-SNAPSHOT.

[twogee]

I'm not quite following your versioning (are you using branch name as version? are X and X.Y branch names then?), but the change proposed by Arnaud does the following

versionRange = VersionRange.createFromVersionSpec(mavenParameters.getVersionRangeWithProjectVersion());
if (pluginParameters.getParameterParam().isUseSemanticVersioningOrderingToResolvePreviousVersion()) {
    versionRange = SemanticVersionRange.getFromExistingVersionRange(versionRange);
}

The question is whether SemanticVersionRange does the right thing for you when building the range, or if it needs to be fiddled with further. If you would be willing to try it out, I could push my branch (where I rebased Arnaud's changes) to GitHub.

[tommy-bo]

Yes, we use branch name as version during development of features. The checked in pom will for example have version 2-SNAPSHOT. Before building this version we have a plugin that resolves the branch name and then we run versions:set with the branch name as newVersion. Thus the build will not contain a semantic version. However, this version change is never commited back to git. We'll probably have to run japicmp in a separate build step without changing the version. This means that we need to compare version 2-SNAPSHOT to the latest 2.x.y-version. 2-SNAPSHOT is technically still incorrect according to the semver-spec, so by the looks of it #172 will not solve our issue.

However, I think our versioning algorithm could do with a little update and rather use the mechanics defined in the semver-spec to mark our features during development. I'll close this issue for now while we evaluate the possibility to make these changes internally.