+1 for 2) Having in mind the pain our dev and ops teams felt while stabilizing the software enough times in the past, definitely #2
—Gancho > On Feb 7, 2018, at 11:52 AM, Leif Hedstrom <zw...@apache.org> wrote: > > > >> On Feb 7, 2018, at 11:47 AM, Leif Hedstrom <zw...@apache.org> wrote: >> >> Hi all, >> >> discussed this with a few of you, but I’d like to take this to the >> community. There’s some requests to get features back ported to 7.1.x, which >> I’m for now postponing to a possible future 7.2.x release. This was the >> intention of the proposal we agreed upon last year, to bring stability as >> well as agility to our release process. >> >> Now, I’m not strongly opposed to allowing for new features to go into say a >> v7.1.3 release, however, before we do so, I’d like to make sure that this is >> *really* what we want to do going forward. I care mostly about consistency, >> such that there’s no arguing as to “why did amc’s feature get into v7.1.3, >> whereas my future has to wait until v7.2.0 or v8.0.0”. >> >> Fwiw, 7.1.1 - 7.1.3 thus far has avoided adding new features to the 7.1.x >> branch. So going forward, I think we have two options: >> >> 1) Allow “safe” (where “safe” is defined by the RM) features to go into >> any patch releases. >> >> 2) Stick with the original plan, and only allow new features in either >> major, or minor releases (e.g. v7.2.0 or v8.0.0). >> >> >> >> >> If we change our policy to #1, I think we should eliminate the plans for >> doing minor releases, i.e. v8.0.x will be the only release in the v8.x >> release cycle. >> > > > Forgot, there’s a column with the current v7.2.0 candidates on this page: > > https://github.com/apache/trafficserver/projects/3? > <https://github.com/apache/trafficserver/projects/3?> > > > > I imagine if we change policy to #1 above, we’ll merge all these into v7.1.3 > or v7.1.4. > > — leif
