One problem that I see is that it appears we are cutting branches extremely early. I'm going to pick on branch-1.4 for a moment. This branch has existed (as far as I can remember) for at least 3-6 months, yet we still have not had a 1.4.0 release. I understand that releases can take time, but this adds pain for developers (If I'm developing a new feature or bug fix, do I put it on branch-1 and it will be pulled into branch-1.4 or do I need to explicitly put it on branch-1.4?). It seems that this branch should be the same as branch-1 at the moment.
So my suggestion would be use branch-1 (or branch-2 now) for all development and only create a branch when the first release of a line is imminent. Perhaps I am missing some context, but that is my 2 cents. Thanks, Zach On Tue, Aug 8, 2017 at 9:14 AM, Mike Drob <md...@apache.org> wrote: > > The discussion also brought up the notion of an LTS release line. I'm not > > sure how this jives with the more fequent minors, but would require some > > branch that's so stable that an RM can effectively spin releases blind. > > Seems to me like this branch would necessarily need to be very > backport-light? Only the top of the highest priority issues would be > backportable to it, no? > > On Tue, Aug 8, 2017 at 11:09 AM, Nick Dimiduk <ndimi...@apache.org> wrote: > > > Last time we DISCUSSed EOL of 1.1 was back in November. At that time, a > > litany of issues were raised re: 1.2. Have those concerns been addressed? > > It seems to me that making this one the last release is too abrupt to > folks > > tracking Apache. Would be better to give some notice. > > > > Had a nice hallway conversation a couple months back (at PhoenixCon, as > it > > happens; they feel the pain as well) about our branch situation. I'll let > > the others chime in with more details, but the gist as I recall is that > we > > should be doing more frequent minor releases with fewer patch releases. > > This pushes stabilization efforts closer to master and also imposes more > > strict stability requirements on big new features before they can be > merged > > off the feature branch. > > > > The discussion also brought up the notion of an LTS release line. I'm not > > sure how this jives with the more fequent minors, but would require some > > branch that's so stable that an RM can effectively spin releases blind. > > > > On Tue, Aug 8, 2017 at 12:14 AM Stack <st...@duboce.net> wrote: > > > > > (This came up during dev meeting in Shenzhen) We are running too many > > > branches and/or when applying patches, we do not do a good job > > backporting > > > to all active branches, especially fixes. > > > > > > We have master, branch-2, branch-1, branch-1.4, branch-1.3, branch-1.2, > > and > > > branch-1.1 active currently. If a dirty bug fix, the applier is > > backporting > > > to 7 branches. It takes a while applying to all especially if the > > backport > > > doesn't go in clean. I suppose the RM could monitor all upstream of > them > > > and then pull wanted patches back (we could do that too) but seems > like a > > > burden on an RMer. > > > > > > We should EOL a few? > > > > > > Nick is on branch-1.1 release at the moment. Perhaps this could be the > > last > > > off branch-1.1. > > > > > > 1.2 hosts our current stable release though 1.3 is out. How about we > cut > > a > > > release off 1.3, call it stable, and then EOL 1.2 after another release > > or > > > so? > > > > > > What you all think? > > > > > > Thanks, > > > S > > > > > >
