[ImageJ-devel] SemVer policies for ImageJ2 and Fiji
saalfelds at janelia.hhmi.org
Sun Mar 15 21:38:42 CDT 2015
Dear ImageJ developers,
my earlier statement about the conclusion that can be drawn from
bubbling versions in a deployment context are wrong.
Counter proof: Artifact X fixes a bug in one of its public methods, and
accordingly increases the PATCH counter. Artifact Y depends on artifact
X and knew about the bug and had a workaround in place to compensate for
it. On upgrade of dependency version for X, it removes the workaround,
public API remains unchanged. This is a patch and X had increased the
PATCH counter, so Y increases the PATCH counter. Neither X nor Y can be
deployed independently. The deployment system (or person) has to
inspect the entire dependency tree to calculate a correct state or a
conflict. The same is true in the non-bubbling situation. Ergo,
bubbling versioning has no advantage over non-bubbling versioning in a
This leads me to the conclusion that non-bubbling versioning is better
because it carries local information for developers that non-bubbling
versioning does not, i.e. in what way the API of the versioned artifact
I expect to be wrong still and that I missed something important.
Looking forward to your responses.
On Sat, 2015-03-14 at 23:12 -0400, Stephan Saalfeld wrote:
> Dear list,
> a recent SPIM_Registration bug report on GitHub
> resulted in a discussion about the correct way of assigning version
> numbers to individual artifacts.
> We have earlier settled to follow SemVer
> which has reasonably clear guidelines under what circumstances to
> increase which of three version counters.
> <quote src="http://semver.org/">
> 1. MAJOR version when you make incompatible API changes,
> 2. MINOR version when you add functionality in a backwards-compatible
> manner, and
> 3. PATCH version when you make backwards-compatible bug fixes.
> It is unspecified, however, how version changes in dependency artifacts
> affect the version of the consuming artifact, i.e. do they bubble or do
> they not? In my current understanding, there are two competing
> objectives, deployment (advocated and executed by @dscho and @ctrueden),
> and development (advocated and executed by @axtimwalde and @ctrueden, we
> see that @ctrueden is ambivalent, @axtimwalde too, as always, just that
> you know):
> Developer perspective: Don't bubble! Developers that use the public API
> of an artifact X in their code use SemVer to reason whether on upgrade
> of X they will have to change their code or simply recompile with no
> modification. Dependency version bubbling would break this contract,
> because it signalizes API incompatibility in X when a dependency Y of X
> introduces incompatible changes, although this incompatibility does not
> affect the public API of X. Deployment of a set of artifacts following
> this contract requires complete inspection of the entire set of
> artifacts to guarantee consistency of the deployed version by other
> means (maven pom tracing?) because the SemVer versions of individual
> artifacts do not encode the necessary information. I have the
> impression that the developer perspective, ignoring it not being helpful
> for deployment, was the driver of the SemVer specification and have a
> preference for it because...
> Deployer perspective: Bubble? Deployers could use SemVer to reason
> whether a new version of an artifact has ANY incompatible changes
> anywhere in its dependency tree. This is useful to know when an
> artifact in the tree can be released *without* considering its
> dependents *and* dependencies (PATCH increase). However, whenever the
> version number signalizes incompatibility (MAJOR) or new features
> (MINOR), further inspection of the entire dependency tree is required
> because consistency cannot be derived from SemVer versions alone. The
> only definite conclusion that can be made from observing that an
> artifact changes its MAJOR or MINOR version, i.e. becomes incompatible,
> is that all dependents will need to be updated/ recompiled or that
> there's a problem, consistency across artifacts cannot be guaranteed.
> I.e. the bubbling scheme, at every individual artifact, sends a signal
> when further inspection is required. This information, however is
> binary, and a single counter would suffice to do that. If patch
> counters are desired, one would need two. The MAJOR and MINOR counters
> are redundant.
> Non-bubbling SemVer tells a developer whether her code will compile with
> a given dependency artifact (PATCH and MINOR). Bubbling SemVer tells a
> deployer when a single artifact can be deployed without considering its
> environment (PATCH). Both things exclude each other. In this setup, I
> find the benefit for developers stronger and therefore prefer
> non-bubbling SemVer.
> An interesting animal are dependency management poms (BOMs) such as
> pom-fiji or pom-mpicbg. Their `public API' is the composite of managed
> dependencies and therefore it has to bubble the SemVer versions of the
> managed dependencies. This is different from artifacts that consume a
> dependency, consuming and managing are different. I may be wrong, but I
> have the impression that these two things often get confused.
> Please let me know your thoughts.
More information about the ImageJ-devel