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. On Fri, Dec 7, 2018 at 5:54 PM 张铎(Duo Zhang) <palomino...@gmail.com> 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 <apurt...@apache.org> 于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) <palomino...@gmail.com> > > 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 <st...@duboce.net> 于2018年12月8日周六 上午4:15写道： > > > > > > > On Fri, Dec 7, 2018 at 11:36 AM Andrew Purtell <apurt...@apache.org> > > > > 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
