Infusion dev numbering proposal

Justin Obara obara.justin at gmail.com
Mon Jan 9 15:13:26 UTC 2017


Hi Everyone,

*In regards to Antranig’s proposal:*

If I’m reading Semver spec point 9 <http://semver.org/#spec-item-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 <http://semver.org/#spec-item-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 (
https://issues.fluidproject.org/browse/FLUID-6104 )

*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
<https://github.com/fluid-project/infusion/tree/infusion-1.4.x>, 1.5.x
<https://github.com/fluid-project/infusion/tree/infusion-1.5.x> and 1.9.x
<https://github.com/fluid-project/infusion/tree/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 raisingthefloor.org)
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 at colorado.edu> 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
> 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
> _______________________________________________________
> fluid-work mailing list - fluid-work at lists.idrc.ocad.ca
> To unsubscribe, change settings or access archives,
> see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
>

_______________________________________________________
fluid-work mailing list - fluid-work at lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.idrc.ocad.ca/pipermail/fluid-work/attachments/20170109/2b6271e7/attachment.html>


More information about the fluid-work mailing list