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 <colinbdcl...@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.jus...@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.jus...@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 (t...@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.jus...@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 (t...@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@ >> 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@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@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@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@lists.idrc.ocad.ca To unsubscribe, change settings or access archives, see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
