On Fri, Dec 7, 2018 at 5:59 PM Andrew Purtell <apurt...@apache.org> 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) <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 >
