Infusion dev numbering proposal

Antranig Basman antranig.basman at colorado.edu
Thu Jan 5 19:13:03 UTC 2017


One outcome from our community meeting on 21st Dec 2016 looking forward to Infusion beyond the 2.0 release 
was a proposal that we change our system for numbering dev releases of Infusion. Until now we have operated 
a policy that the version number of Infusion in trunk is derived from the *next* version of Infusion to be 
released - for example, our package.json has shown a version of 2.0.0 for many months, and our "in-code" 
namespace version has been fluid_2_0_0.

This also implies that all dev releases made to date via the fluid-publish module have been of the form 
2.0.0-dev.xxxxxxxxx

The proposal (currently enjoying the status of "silent acceptance" by virtue of this still being the 
condition of trunk after the release) is that we leave all these versions just as they are, and flip our 
policy so that the versions shown in trunk will from henceforth always represent the *previous* release 
rather than the upcoming release.

The reasons for this are primarily driven by semver semantics http://semver.org/ - it would seem impossible 
to anticipate before the fact whether the upcoming release will be a major, minor, or patch version - this 
status could change on the basis of a single commit, and it seems too much of a burden, as well as highly 
noisy, to expect that anyone merging a pull request which in effect changes the status of the upcoming 
release to do the work of renumbering all the versions in trunk.

There had been a further driver in the form of a bug in fluid-publish which has since been fixed in the 
branch currently in review - https://github.com/fluid-project/fluid-publish/pull/5 - that the "most recently 
published dev release" would supersede all previous proper releases. This is no longer relevant since the 
bug has been fixed. However, adopting this policy will create the oddity that pre-2.0 release and post-2.0 
(but pre next official) release dev releases of Infusion will be somewhat indistinguishable in that they 
will all have versions of the form 2.0.0-dev.xxxxxxxxx - however, this is where our dev release numbering 
policy comes in handy in that we can still refer to the date field to note that any of these dated after Dec 
6th 2016 (e.g. 2.0.0-dev.20161219T170555Z.5778f7e) must be post-2.0 release dev releases.

Any comments/suggestions?

Cheers,

Antranig


More information about the fluid-work mailing list