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

[Stephan Saalfeld]

+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.