[ImageJ-devel] Opinion needed: POM parent versioning

Tue Nov 18 08:08:27 CST 2014

I also vote for SemVer, we got used to it :)

> On Nov 17, 2014, at 15:31 , Tobias Pietzsch <tobias.pietzsch at gmail.com> wrote:
> 
> Hi Curtis,
> 
> I would prefer SemVer, but mainly because this seems closer to the way its currently done and I’m getting used to that way. So really no strong opinion at all.
> 
> What would be nice would be some kind of notification when new pom parents are released. When revisiting some projects I haven’t been working on for a while, I often find myself checking maven.imagej.net <http://maven.imagej.net/> to find out, eg, what the latest pom-fiji version is, so that I can use the latest and greatest as a parent. Is there already some mailing-list or similar in place that sends such release notifications?
> 
> best regards,
> Tobias
> 
> On 17 Nov 2014, at 20:39, Curtis Rueden <ctrueden at wisc.edu <mailto:ctrueden at wisc.edu>> wrote:
> 
>> 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.
>> 
>> -- 
>> You received this message because you are subscribed to the Google Groups "scijava" group.
>> To unsubscribe from this group and stop receiving emails from it, send an email to scijava+unsubscribe at googlegroups.com <mailto:scijava+unsubscribe at googlegroups.com>.
>> For more options, visit https://groups.google.com/d/optout <https://groups.google.com/d/optout>.
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups "scijava" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to scijava+unsubscribe at googlegroups.com <mailto:scijava+unsubscribe at googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout <https://groups.google.com/d/optout>.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://imagej.net/pipermail/imagej-devel/attachments/20141118/65cbe4c5/attachment-0001.html>