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
> What you all think?