<div dir="ltr"><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div>Hi Stephan,<br><br></div><div>Thanks for starting this thread!<br><br></div><div>For those interested, there was further <a href="http://code.imagej.net/chatlogs/imagejdev?times=prefix&start-date=2015-03-16&end-date=2015-03-16#20150316T155138">discussion in IRC</a> today, and Curtis and I chatted briefly face-to-face.<br><br></div><div>Basically, we agree that semver must be limited in scope to the public API of a given project. Checking for dependency convergence must be handled separately. Bubbling versions through dependencies is not significantly meaningful.<br><br></div><div>Documentation on this (and other versioning issues) is on the wiki: <a href="http://imagej.net/Architecture#Versioning">http://imagej.net/Architecture#Versioning</a><br></div><div><br>>Artifact Y depends on artifact X and knew about the bug and had a workaround in place to compensate for it<br><br></div><div>As a side note, semver does not guarantee preservation of unintentional behavior. As long as behavior is fixed in a way that's backwards-compatible with public API, only patch versions need to change.<br><br></div><div>However, the idea is that a BOM will account for such a change, to avoid dependency skew.<br><br></div><div>Best,<br></div><div>Mark<br></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div><div><div><div><div><div><div><div><div><div><div><div><div><br></div></div></div></div></div></div></div></div></div></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Mar 15, 2015 at 9:38 PM, Stephan Saalfeld <span dir="ltr"><<a href="mailto:saalfelds@janelia.hhmi.org" target="_blank">saalfelds@janelia.hhmi.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Dear ImageJ developers,<br>
<br>
my earlier statement about the conclusion that can be drawn from<br>
bubbling versions in a deployment context are wrong.<br>
<br>
Counter proof: Artifact X fixes a bug in one of its public methods, and<br>
accordingly increases the PATCH counter. Artifact Y depends on artifact<br>
X and knew about the bug and had a workaround in place to compensate for<br>
it. On upgrade of dependency version for X, it removes the workaround,<br>
public API remains unchanged. This is a patch and X had increased the<br>
PATCH counter, so Y increases the PATCH counter. Neither X nor Y can be<br>
deployed independently. The deployment system (or person) has to<br>
inspect the entire dependency tree to calculate a correct state or a<br>
conflict. The same is true in the non-bubbling situation. Ergo,<br>
bubbling versioning has no advantage over non-bubbling versioning in a<br>
deployment context.<br>
<br>
This leads me to the conclusion that non-bubbling versioning is better<br>
because it carries local information for developers that non-bubbling<br>
versioning does not, i.e. in what way the API of the versioned artifact<br>
was changed.<br>
<br>
I expect to be wrong still and that I missed something important.<br>
<br>
Looking forward to your responses.<br>
<br>
Thanks,<br>
Stephan<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
On Sat, 2015-03-14 at 23:12 -0400, Stephan Saalfeld wrote:<br>
> Dear list,<br>
><br>
> a recent SPIM_Registration bug report on GitHub<br>
><br>
> <a href="https://github.com/bigdataviewer/SPIM_Registration/issues/10#issuecomment-79721014" target="_blank">https://github.com/bigdataviewer/SPIM_Registration/issues/10#issuecomment-79721014</a><br>
><br>
> resulted in a discussion about the correct way of assigning version<br>
> numbers to individual artifacts.<br>
><br>
> We have earlier settled to follow SemVer<br>
><br>
> <a href="http://semver.org/" target="_blank">http://semver.org/</a><br>
><br>
> which has reasonably clear guidelines under what circumstances to<br>
> increase which of three version counters.<br>
><br>
> <quote src="<a href="http://semver.org/" target="_blank">http://semver.org/</a>"><br>
> 1. MAJOR version when you make incompatible API changes,<br>
> 2. MINOR version when you add functionality in a backwards-compatible<br>
> manner, and<br>
> 3. PATCH version when you make backwards-compatible bug fixes.<br>
> </quote><br>
><br>
> It is unspecified, however, how version changes in dependency artifacts<br>
> affect the version of the consuming artifact, i.e. do they bubble or do<br>
> they not? In my current understanding, there are two competing<br>
> objectives, deployment (advocated and executed by @dscho and @ctrueden),<br>
> and development (advocated and executed by @axtimwalde and @ctrueden, we<br>
> see that @ctrueden is ambivalent, @axtimwalde too, as always, just that<br>
> you know):<br>
><br>
> 1.<br>
> Developer perspective: Don't bubble! Developers that use the public API<br>
> of an artifact X in their code use SemVer to reason whether on upgrade<br>
> of X they will have to change their code or simply recompile with no<br>
> modification. Dependency version bubbling would break this contract,<br>
> because it signalizes API incompatibility in X when a dependency Y of X<br>
> introduces incompatible changes, although this incompatibility does not<br>
> affect the public API of X. Deployment of a set of artifacts following<br>
> this contract requires complete inspection of the entire set of<br>
> artifacts to guarantee consistency of the deployed version by other<br>
> means (maven pom tracing?) because the SemVer versions of individual<br>
> artifacts do not encode the necessary information. I have the<br>
> impression that the developer perspective, ignoring it not being helpful<br>
> for deployment, was the driver of the SemVer specification and have a<br>
> preference for it because...<br>
><br>
> 2.<br>
> Deployer perspective: Bubble? Deployers could use SemVer to reason<br>
> whether a new version of an artifact has ANY incompatible changes<br>
> anywhere in its dependency tree. This is useful to know when an<br>
> artifact in the tree can be released *without* considering its<br>
> dependents *and* dependencies (PATCH increase). However, whenever the<br>
> version number signalizes incompatibility (MAJOR) or new features<br>
> (MINOR), further inspection of the entire dependency tree is required<br>
> because consistency cannot be derived from SemVer versions alone. The<br>
> only definite conclusion that can be made from observing that an<br>
> artifact changes its MAJOR or MINOR version, i.e. becomes incompatible,<br>
> is that all dependents will need to be updated/ recompiled or that<br>
> there's a problem, consistency across artifacts cannot be guaranteed.<br>
> I.e. the bubbling scheme, at every individual artifact, sends a signal<br>
> when further inspection is required. This information, however is<br>
> binary, and a single counter would suffice to do that. If patch<br>
> counters are desired, one would need two. The MAJOR and MINOR counters<br>
> are redundant.<br>
><br>
> Short:<br>
> Non-bubbling SemVer tells a developer whether her code will compile with<br>
> a given dependency artifact (PATCH and MINOR). Bubbling SemVer tells a<br>
> deployer when a single artifact can be deployed without considering its<br>
> environment (PATCH). Both things exclude each other. In this setup, I<br>
> find the benefit for developers stronger and therefore prefer<br>
> non-bubbling SemVer.<br>
><br>
> An interesting animal are dependency management poms (BOMs) such as<br>
> pom-fiji or pom-mpicbg. Their `public API' is the composite of managed<br>
> dependencies and therefore it has to bubble the SemVer versions of the<br>
> managed dependencies. This is different from artifacts that consume a<br>
> dependency, consuming and managing are different. I may be wrong, but I<br>
> have the impression that these two things often get confused.<br>
><br>
> Please let me know your thoughts.<br>
><br>
> Thanks,<br>
> Stephan<br>
><br>
><br>
><br>
<br>
</div></div></blockquote></div><br></div>