Allow some kind of "releaseBuildVersion"

[laeubi]

Currently we have a strict rule that .qualifier enforces -SNAPSHOT versions that is not always desirable.

We have two cases for example:

1. I don't mind about snapshots whatever and want a pom version of x.y.z but the bundle should still have qualifiers
2. I want to use CI Friendly versions and as part of this might use -SNAPSHOT or not

For option two the workflow might be as follows:

• I have always x.y.z-SNAPSHOT in my poms
• If i want to perform a release i run maven with -Drevision=x.y.z and deploy my stuff
• I update all versions to x.y.(z+1)-SNAPSHOT (or what ever suffice)
• Just go ahaed

[mickaelistria]

Note that 1 limitation of CI Friendly versions is that they assume all modules will use the same value for those properties. While it can be interesting for some cases, it's not how most Eclipse project like to deal with their qualifiers.
But indeed, if we can allow CI Friendly Versions, it's probably a good step towards removing this -SNAPSHOT<=>.qualifier constraint.

[laeubi]

Note that 1 limitation of CI Friendly versions is that they assume all modules will use the same value for those properties.

I think this could still be archived, see the example from the documentation here:

<project>
    <modelVersion>4.0.0</modelVersion>
    <parent>
      <groupId>org.apache</groupId>
      <artifactId>apache</artifactId>
      <version>18</version>
    </parent>
    <groupId>org.apache.maven.ci</groupId>
    <artifactId>ci-parent</artifactId>
    <name>First CI Friendly</name>
    <version>${revision}${sha1}${changelist}</version>
    ...
    <properties>
      <revision>1.3.1</revision>
      <changelist>-SNAPSHOT</changelist>
      <sha1/>
    </properties>
  </project>

Each module can have its own <revision> and you can still do mvn -Dchangelist= clean package to have a "non-snapshot" / "release" build

[mickaelistria]

Each module can have its own

Ah, that's pretty interesting. However is this module-specific revision set? Could it be something the build-qualifier-mojo could set? I guess it runs too late...

[laeubi]

I have not tested it, but think it should must run as an AbstractLifecycleParticipant in the "after projects read" phase this would probably the latest opportunity to do so but I haven't debugged it yet. Anyways we could always try to get a change in Maven itself to support such things as a maven-core-extension (haven't yet checked either).
I'm just wondering if this is neccesary, do you like to have a version that is not snapshot but -BUILDqualifier instead?

[mickaelistria]

I'm just wondering if this is neccesary, do you like to have a version that is not snapshot but -BUILDqualifier instead?

I'm just thinking that if we make revision be the qualifier, we may be able to put <version>1.2.0.${revision}</version> in pom files, so we'd still fit under (current) Tycho constraint that pom version must match OSGi version and have the same exact version between Maven and p2, bringing more consistency.

[laeubi]

'm just thinking that if we make revision be the qualifier, we may be able to put <version>1.2.0.${revision}</version> in pom

For current behavior you could use <version>1.2.0${revision}</version> and <revision>-SNAPSHOT</revision> and use in Manifest 1.2.0.qualifier

[mickaelistria]

I would like to have the exact same version in (consumer) pom and MANFEST.MF, so basically I'd like to get rid of -SNAPSHOT and replace it with the value of the expanded qualifier. Ideally, I'd like to have that in an "expressive" way, that appears in Maven, not as a hook that alters the consumer pom GAV as it's really unexpected in most cases, ${revision} is pretty expresssive and sets the right expectations.

[laeubi]

For that purpose one could argue to not using the qualifier at all and simply manage the full version by hand (as we already require an increment on each change). Anyways it would be handy to have {sha1} been populated by jgit plugin, but as said I havent investigated how these CI-Versions works inside maven.

[laeubi]

I have now digged a bit into how maven works here and the version is interpolated at the Modelbuilding stage (that's where Tycho-pomless intercept to generate a model from the eclipse meta-data). I think we can intercept here, but one should keep in mind that there is not much setup yet. One could also intercept in the graphbuilding stage as this is where things come to action and no component has actually seen the version.

That said, it might be more promising to migrate to a pomless build and replace the .qualifier there already and the pom versions would be generated automatically.

[laeubi]

Some more observations:

1. DefaultBuildTimestampProvider is inherently save to use anywhere as it just uses the timestamp and nothing else
2. JGitBuildTimestampProvider uses the MojoExecution so would require a Mojo to be executed, but actually only uses the configuration, we probably can better pass Xpp3Dom here then it should also work in other build-stages.
3. BuildQualifierMojo sets some properties, this could for sure happen in the setup phase, but has a strange 'forceContextQualifier' read from build-properties. We could for sure read that without the rest of tycho anyways...

So the bottom line is, we should be able to calculate and inject the qualifier in the new build-extension I'm just a bit uncertain if it is a good idea.

Eclipse currently enforces me to change the micro version already if there is a change in the current release-cycle. I think it wont harm to force it to change it on any change as mostly projects already use the x.y.100 .. x.y.200 .. x.y.300 between releases one could simply do a x.y.100 .. x.y.101 ... x.y.102 in a release cycle and thus drop qualifier/snapshot at all.

[mickaelistria]

I think it wont harm to force it to change it on any change

Eclipse Project wouldn't accept a workflow or a tool that requires to bump version on every change.
Eclipse Project uses continuous delivery of snapshots, with baseline replacement of snapshots, using snapshot as baseline, and several bundles receive hundreds of changes per release. We don't want Platform contributor to bump version on every change, and we don't want to produce 100 different versions. We just want to work on 1 stream/version and release its latest snapshot.

[laeubi]

Here is some discussion/concerns https://bugs.eclipse.org/bugs/show_bug.cgi?id=382482

[mickaelistria]

So the bottom line is, we should be able to calculate and inject the qualifier in the new build-extension I'm just a bit uncertain if it is a good idea.

I personally think it's pretty good and it's not specific to Tycho but valuable to wider Maven and consistent with what Maven is trying to achieve with "Ci-Friendly" versions. Maven has opened itself to properties allowing to dynamically set the Maven version (just like .qualifier has allowed in OSGi/PDE world for 2 decades), so it seems like the more natural way to deal with dynamic version here would be to leverage this feature, and since -as you mentioned- JGit can work without Tycho, it can be a jgit-revision-plugin extension that can dynamically set the ${revision} for each Maven project.

[laeubi]

I personally think it's pretty good and it's not specific to Tycho but valuable to wider Maven

I have opened apache/maven#674 for that so if you think you can bring that forward that would be a perquisite.

[mickaelistria]

I think the requirements here are covered by #611. If something is missing, we'll then open new issues.