Infusion dev numbering proposal
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
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.
More information about the fluid-work