+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+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. _______________________________________________ ImageJ-devel mailing list ImageJ-devel@imagej.net http://imagej.net/mailman/listinfo/imagej-devel
