[ImageJ-devel] Opinion needed: POM parent versioning

[Curtis Rueden]

Hi everyone,

This is a question for anyone consuming the pom-* parents of the SciJava
software stack.

We want to start versioning these POM parents according to consistent
rules. (Unfortunately, right now, the approach is vague and potentially
inconsistent [1].) We came up with the following two possible schemes, and
would like your feedback on which one you would prefer.

== 1) SemVer ==

Every POM parent has three digits, X.Y.Z.

The X digit is "major" and when incremented indicates a breaking change of
some sort: either A) plugin config changes requiring downstream changes, or
more commonly B) major SemVer dependency version bumps (e.g., managed
scijava-common version updated from 2.35.0 to 3.0.0). This would exclude
0.x and beta components though (so e.g. imglib2-realtransform could go from
2.0.0-beta-27 to 2.0.0-beta-28 without bumping pom-imglib2's X digit).

The Y digit is "minor" and incremented when dependency versions change in a
SemVer-compatible manner, or when plugin configuration is added or improved.

For critical bug-fixes where a given POM parent is somehow compromised or
broken, the third digit Z can be bumped before going to the next Y. (See
e.g. the recent pom-fiji 5.0.Z series of releases.)

== 2) Bread crumb version trail ==

The pom-scijava parent would have a single version digit. The pom-imagej
(which is the next POM down) would have two: the first in lockstep with its
pom-scijava parent, and the second being its dedicated version digit. POMs
which extend pom-imagej (i.e.: pom-scifio, pom-imglib2 and pom-fiji) would
have three digits: the first two in lockstep with pom-imagej and the third
their own. And so on down the line—e.g., pom-trakem2 would need four
digits: the first three matching the pom-fiji parent and the fourth its own.

== Pros and cons ==

Option 1:
[PRO] Semantic meaning. You can reason whether a given POM is somehow
"breaking".
[PRO] Succinctness. Every parent POM has at most three digits at any one
time.
[CON] Lack of provenance. Not obvious which parent POMs go together without
leaning on a tool.

Option 2:
[PRO] Clear provenance. You can trivially derive the chain of parent POM
versions.
[CON] Lack of semantics. Harder to tell which POM parent releases might
break backwards compatibility.
[CON] Aesthetics. More than 3 digits in a version string may not be
desirable.

Note that either way, we are in the process of creating a
scijava-maven-plugin goal to dump all the component version properties
associated with a given parent POM.

Since either scheme is consistent and useful, we want to institute
whichever scheme will annoy everyone less. ;-) So which do people like
better: SemVer or breadcrumbs?

Thanks,
Curtis

[1] The 5.x POM versioning approach was an attempt to achieve _both_
options above, but Mark & I realized today that the two goals are rather
mutually exclusive. That is, we cannot keep POM parent versions fully in
lockstep while also maintaining a SemVer versioning scheme.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://imagej.net/pipermail/imagej-devel/attachments/20141117/023afd42/attachment-0001.html>