I think Andrew's way makes sense for branch-1, we can release 1.6,1.7 and so on directly on branch-1. Since in branch-1, we will only have bug fixes. If we want to apply this policy to branch-2, we'd be careful when new functions check in, because all feature releases will include this function if we only have a branch-2. But good news is that we only need to commit our code to one branch, for now, sometimes I need to commit to four branches(branch-2.0, branch-2.1, branch-2 and master). And for users, they don't have to make difficult chose about which release line they need to use. And they don't have to consider about compatibility when upgrading a minor version. We make sure all the Incompatible changes are only commit to master branch(for releasing 3.x).
Best Regards Allan Yang Stack <[email protected]> 于2018年12月9日周日 上午7:35写道： > On Fri, Dec 7, 2018 at 5:59 PM Andrew Purtell <[email protected]> wrote: > > > We could do that. Or we could simply renumber branch-1 to 1.6.x at that > > time, e.g. 1.5.whatever-SNAPSHOT -> 1.6.0-SNAPSHOT. Every release has a > tag > > in rel/. It is possible at any time to check out from a release tag and > > make a branch for an additional patch release for an old minor line. If > we > > need to do it, we can at that time, otherwise why proliferate branches > and > > make more work for committers? I think for branch-1 after moving from > > 1.5.whatever to 1.6.0 any additional 1.5.x releases would be unlikely, > and > > going forward for 1.6, and so on. This same policy could work for > branch-2. > > We shouldn't be afraid to make new minors. Prior to 1.0.0 every release > was > > a minor release and patch releases were rare. I think we want to get back > > to something more like that. > > > > It also makes sense to have a long term stable branch. That is currently > > branch-1.2. If in the future we want it to be 1.5, then at that time it > > makes sense to have a separate branch-1.5 for the LTS. > > > > > Let's try it. > > Should be easy to do on branch-1 what with a single 'owner'. > > branch-2 would prove a more interesting experiment. Let branch-2 be where > we cut 2.2.0 and 2.2.1, etc., from? (We need an RM for 2.2....) > > S > > > > > > > > On Fri, Dec 7, 2018 at 5:54 PM 张铎(Duo Zhang) <[email protected]> > > wrote: > > > > > If 1.5 is not the last minor release line, then how do we release 1.6? > > Make > > > a branch-1.5 and then start to release 1.6 from branch-1? > > > > > > Andrew Purtell <[email protected]> 于2018年12月8日周六 上午9:36写道： > > > > > > > Yeah, for branch-1 it is no longer a development branch. Every change > > is > > > > going to be maintenance related. No, I don't expect 1.5 to be the > last > > > > minor release line for 1.x. Maybe? Maybe not. In theory we could > treat > > > > branch-2 the same. Master is the only development branch. That is not > > my > > > > proposal, though. I'm only concerned with RM activities related to > > > > branch-1. > > > > > > > > On Fri, Dec 7, 2018 at 5:33 PM 张铎(Duo Zhang) <[email protected]> > > > > wrote: > > > > > > > > > So the idea is that, if we have a newer major release line, we can > > > > release > > > > > the previous major releases directly from the 'developing' branch? > > > > > > > > > > I think for branch-1 it is fine, as we are not likely to backport > any > > > big > > > > > new feature to 1.x any more. And does this mean that 1.5 is the > last > > > > minor > > > > > release line for 1.x? > > > > > > > > > > Stack <[email protected]> 于2018年12月8日周六 上午4:15写道： > > > > > > > > > > > On Fri, Dec 7, 2018 at 11:36 AM Andrew Purtell < > > [email protected]> > > > > > > wrote: > > > > > > > > > > > > > Please be advised I plan to RM the next minor release from > > > branch-1, > > > > > > 1.5.0, > > > > > > > in January of 2019. Once this is done we can continue making > > > > > maintenance > > > > > > > releases from branch-1.4 as needed but expect that not to be > > > > necessary > > > > > > > after a couple of months (or perhaps even immediately). > > > > > > > > > > > > > > I see no need to make a branch-1.5. As community resources > > continue > > > > to > > > > > > > shift away from branch-1 we need to conserve available > > attention. I > > > > > don't > > > > > > > see why we cannot release directly from branch-1. Certainly in > > the > > > > > > > beginning any branch-1.5 would be lock step with branch-1. No > > > > > distinction > > > > > > > in branch curation means no need for a new branch, at least > > > > initially. > > > > > > > Also, should a commit land in branch-1 that requires a new > minor > > > per > > > > > our > > > > > > > compatibility guidelines then I don't see why the next release > > from > > > > > > > branch-1 cannot a new minor (1.6.0, etc.) right there and then. > > We > > > > have > > > > > > > expressed intent to make more frequent minor releases anyhow. > > > > > > > > > > > > > > Related, I started a DISCUSS thread about EOL of branch-1.3. > > > > > > > > > > > > > > In my opinion the optimal future for branch-1, until all > > attention > > > > > moves > > > > > > > away from it, is continuing releases directly from branch-1 and > > > > perhaps > > > > > > > branch-1.2 (depends on Busbey's plans for it). > > > > > > > > > > > > > > If you would prefer we continue to make new branches for minor > > code > > > > > > lines, > > > > > > > I can do that for 1.5, no problem, but perhaps you will agree > it > > is > > > > no > > > > > > > longer necessary. > > > > > > > > > > > > > > > > > > > > > Agree. > > > > > > > > > > > > I also like the idea of doing same thing for branch-2. > > > > > > > > > > > > S > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > Best regards, > > > > > > > Andrew > > > > > > > > > > > > > > Words like orphans lost among the crosstalk, meaning torn from > > > > truth's > > > > > > > decrepit hands > > > > > > > - A23, Crosstalk > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > Best regards, > > > > Andrew > > > > > > > > Words like orphans lost among the crosstalk, meaning torn from > truth's > > > > decrepit hands > > > > - A23, Crosstalk > > > > > > > > > > > > > -- > > Best regards, > > Andrew > > > > Words like orphans lost among the crosstalk, meaning torn from truth's > > decrepit hands > > - A23, Crosstalk > > >
