Infusion dev numbering proposal

Tony Atkins tony at raisingthefloor.org
Tue Jan 17 09:28:22 UTC 2017


Hi, Justin.

The eslint-config-fluid project itself has versioned releases, so it's
mainly a matter of nicely coupling them to an appropriate infusion release,
and then making it clear how to override the setting in individual
projects.  IMO the latest release of the eslint-config-fluid project should
refer to the latest major infusion release, which is the baseline.  If a
project is only compatible with a later minor/patch release (or fluid 1.5),
that setting can be overridden in the same eslintrc.json file that brings
in the eslint-config-fluid settings, and details on doing so should be in
the README of eslint-config-fluid.

To summarize, I'm proposing we leave the version reflected in the
eslint-config-fluid global settings at fluid_2_0_0 until 3.0 is released,
and document how to override the setting in the project's README.

Cheers,


Tony

On Mon, Jan 16, 2017 at 6:28 PM, Justin Obara <obara.justin at gmail.com>
wrote:

> One more thing to think about in relation to this issue. What should we do
> about our eslint configuration. In eslint-config-fluid right now we have a
> globals declaration for fluid_2_0_0
> <https://github.com/fluid-project/eslint-config-fluid/blob/master/.eslintrc.json#L6-L8>.
> I’m thinking that this isn’t correct. Maybe we define a global for “fluid”
> and then each project should add a specific version to define as a global
> as needed. Most likely, this will just be in infusion itself.
>
> Thanks
> Justin
>
>
> On January 13, 2017 at 7:36:53 AM, Justin Obara (obara.justin at gmail.com)
> wrote:
>
> +1 to Colin and Tony’s latest suggestions.
>
>
> On January 13, 2017 at 5:29:54 AM, Tony Atkins (tony at raisingthefloor.org)
> wrote:
>
> 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.
>
> Cheers,
>
>
> Tony
>
> On Thu, Jan 12, 2017 at 10:48 PM, Colin Clark <colinbdclark at gmail.com>
> wrote:
>
>> 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 gmail.com>
>> wrote:
>>
>> I’ve filed a task in JIRA for this work/discussion.
>> https://issues.fluidproject.org/browse/FLUID-6105
>>
>> Thanks
>> Justin
>>
>>
>> On January 9, 2017 at 11:57:48 AM, Justin Obara (obara.justin at gmail.com)
>> 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 raisingthefloor.org)
>> 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 <https://docs.npmjs.com/cli/unpublish> 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 gmail.com>
>> wrote:
>>
>>> 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 colora
>>> do.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
>>>
>>>
>> _______________________________________________________
>> 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/20170117/9ff1a871/attachment.html>


More information about the fluid-work mailing list