[ImageJ-devel] [fiji-devel] Opinion needed: POM parent versioning

Christian Dietz christian.dietz at uni-konstanz.de
Tue Nov 18 03:04:28 CST 2014


+1 SemVer. Getting used to it.

On 18.11.2014 03:08, Stephan Saalfeld wrote:
> +1 SemVer
>
>
> On Mon, 2014-11-17 at 13:39 -0600, Curtis Rueden 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.
>> -- 
>> -- 
>> Please avoid top-posting, and please make sure to reply-to-all!
>>   
>> Mailing list web interface: http://groups.google.com/group/fiji-devel
>>
>> ---
>> You received this message because you are subscribed to the Google
>> Groups "Fiji-devel" group.
>> To unsubscribe from this group and stop receiving emails from it, send
>> an email to fiji-devel+unsubscribe at googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>
> _______________________________________________
> ImageJ-devel mailing list
> ImageJ-devel at imagej.net
> http://imagej.net/mailman/listinfo/imagej-devel




More information about the ImageJ-devel mailing list