Infusion dev numbering proposal

Tony Atkins tony at
Fri Jan 13 10:29:13 UTC 2017

Hi, Colin:

Updating master to a future major release version and cutting
minor/patch/releases manually seems like a good balance to me.  We should
talk again as a group if we find ourselves cutting minor/patch releases
often enough that merging becomes a burden.



On Thu, Jan 12, 2017 at 10:48 PM, Colin Clark <colinbdclark at>

> Hi all,
> I wonder if we can find a compromise that is sufficiently low-maintenance
> and informal but still clear to our users and at least within the spirt of
> semver? Given that we're a small community with very ambitious goals and
> limited resources, we should in general try to favour processes that are as
> informal and easy to manage as possible.
> How about this...?
> 1. Always keep the version of master set to the next major release number.
> So, since we've released 2.0.0, master should be set up to publish
> development releases for 3.0.0. When we eventually cut 3.0.0, it will be
> incremented to 4.0.0, and so on. The reality is that we know we're going be
> moving fast and making lots of big changes over the next while as new
> framework features emerge (such as the new Renderer), so we might as well
> assume that our next release will be a major one.
> 2. If we do find the need to cut a smaller 2.0.y or a 2.x.y maintenance
> release due to major bugs or features, we simply do what we've done in the
> past and use a release branch, apply or back port any fixes we need into
> this branch when the demand builds up, and then cut a release as needed.
> I think this is essentially doing Justin's bullet #3 below, and only that.
> I don't think it's realistic to try to keep three separate branches in sync
> all the time. That seems like a recipe for mistakes and more release
> bureaucracy.
> And yes, Tony's point about not deleting releases makes a lot of sense.
> Colin
> On Jan 11, 2017, at 11:04 AM, Justin Obara <obara.justin at> wrote:
> I’ve filed a task in JIRA for this work/discussion.
> Thanks
> Justin
> On January 9, 2017 at 11:57:48 AM, Justin Obara (obara.justin at
> wrote:
> Hi Tony,
> Warning and using the deprecated command sound like a good approach.
> Thanks
> Justin
> On January 9, 2017 at 11:41:56 AM, Tony Atkins (tony at
> wrote:
> Hi, Justin:
> I will wait for others to way in further on the branching strategy, but I
> wanted to respond to this point:
>>    - Potentially clean up the erroneous dev builds by deleting them ( if
>>    we can get away with that ), just the ones post 2.0 that were wrong.
> Deleting dev releases is a bad practice, and much more trouble than
> confusing semver ordering.  Builds that rely on the version would break on
> the next commit or test run, for starters.  Package authors would have to
> update before they can resume even testing their own work.  This kind of
> unplanned disruption can cause chaos even if you're just talking about the
> handful of people who use dev builds within our community.  It's better to
> warn everyone and move forward than to potentially and confusingly break
> work in progress.  Even npm themselves strongly discourage unpublishing
> versions <> in the documentation for
> the command used to do so.
> I can see a lot of other strategies here that would accomplish the major
> goal (avoiding confusion between pre and post release), for example,
> flagging the pre-2.0 releases as deprecated (which is what npm suggests).
> Cheers,
> Tony
> On Mon, Jan 9, 2017 at 4:13 PM, Justin Obara <obara.justin at>
> wrote:
>> Hi Everyone,
>> *In regards to Antranig’s proposal:*
>> If I’m reading Semver spec point 9 <> correctly,
>> using 2.0.0-dev.xxxxxxxxx would actually be a pre-release of 2.0.0 as
>> opposed to a pre-release of whatever version comes next. This means that
>> someone following semver would see these as coming before the 2.0.0 release
>> instead of after it.
>> Also, from point 10 <>, it seems we
>> should have actually put the release as 2.0.0-dev+xxxxxxxxx regardless of
>> what approach we take. The “+” indicates that the rest is build meta data.
>> In our case it’s the date and revision hash. I’ve filed a JIRA for this (
>> )
>> *In regards to Tony’s proposal:*
>> We currently have a notion of creating a .x branch to create patch
>> releases from. We currently have 1.4.x
>> <>, 1.5.x
>> <> and 1.9.x
>> <>. We could extend
>> this and have a 2.0.x and 2.x.x lines. I think it would be a lot of work
>> though to be making commits to 3 branches ( 2.0.x 2.x.x and master ) for
>> one change.
>> *My counter proposal:*
>>    - Potentially clean up the erroneous dev builds by deleting them ( if
>>    we can get away with that ), just the ones post 2.0 that were wrong.
>>    - Increment master based on the commits that are merged. That is
>>    start by changing it to 2.0.1, if a commit is going to have something that
>>    warrants a minor release, create a 2.0.1 patch release first ( if there
>>    were changes ). Then bump the release up to 2.1.0, and so on.
>>    - The tricky part comes with a major change, and for that we’d have
>>    to bump the version number up to 3.0.0. We could either carry on from here
>>    as Tony suggested and make a new branch for 2.x work, or we could just
>>    assume everything else will be part of the next major release.
>> I wouldn’t say this is the ideal solution, but it might be easiest.
>> Thanks
>> Justin
>> On January 6, 2017 at 7:35:43 AM, Tony Atkins (tony at
>> wrote:
>> Hi, All.
>> I was thinking about this very thing yesterday.  For the near future, I
>> think Antranig's suggestion is fine.
>> As our community continues to grow, I would argue that we need to adopt a
>> strategy that better supports minor and/or patch releases between major
>> releases.  Although we cannot know whether our next release is major,
>> minor, or a patch, we do know that there will be another release, and it
>> would be good for us to discipline ourselves and learn to at least estimate
>> how big each change we make is.
>> My initial thought is that we would create a branch for the next presumed
>> patch and minor release and leave master for the next major release.  When
>> submitting new work, we would start with whichever branch most closely
>> matches the scope of the change we are making. In choosing a starting
>> branch, each of us implicitly has to think about and discuss the scope of a
>> change with others.
>> So, for example, we have just release 2.0.0 and have not released any
>> later versions.  We could create a 2.0.1 branch, and a 2.1.0 branch, each
>> of which has that version in their package.json.  The version in master
>> would be updated to 3.0.0.   Bug fixes that are backward compatible would
>> be submitted against the 2.0.1 branch.  New features that do not break
>> previous functionality would be submitted against the 2.1.0 branch.
>> Breaking changes would be submitted against master.
>> This requires a bit of extra work when cutting a release.  When we
>> release 2.0.1, we create a 2.0.2 branch.  When we release 2.1.0, we create
>> a 2.2.0 branch and a 2.1.1 branch.  When we release 3.0.0, we create a
>> 3.0.1 branch, and a 3.1.0 branch, and update the master version to 4.0.0.
>> There are existing tools that manage this for you, we could also modify the
>> fluid-publish script to take care of much of this.
>> The branch structure would require some extra work in preparing for a
>> minor or major release, i. e. we would have to make sure to merge upward,
>> merging changes made to the 2.0.1 branch that we want to preserve in 2.1,
>> for example.  This in theory could be largely automatic for patch and minor
>> releases, but would need to be more of a manual process for major releases.
>> As a simpler alternative, I could see us adopting this incrementally, by
>> having a 2.1 branch and master, and at least dividing work according to
>> whether it's appropriate for a minor or major release.  That would
>> represent less additional work in managing branches, but would at least get
>> us started in the important practice of drawing a clear line between
>> breaking and non-breaking changes in future releases.
>> Cheers,
>> Tony
>> On Thu, Jan 5, 2017 at 8:13 PM, Antranig Basman <antranig.basman@
>>> wrote:
>>> 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
>>> - 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 -
>>> - 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
>>> _______________________________________________________
>>> fluid-work mailing list - fluid-work at
>>> To unsubscribe, change settings or access archives,
>>> see
>> _______________________________________________________
>> fluid-work mailing list - fluid-work at
>> To unsubscribe, change settings or access archives,
>> see
> _______________________________________________________
> fluid-work mailing list - fluid-work at
> To unsubscribe, change settings or access archives,
> see
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the fluid-work mailing list