I think we should continue with the original plan: Bug fixes go into the patch level version. New features go into minor releases. Changes to the architecture or APIs should go into the next major release. By having this clear delineation, for example, those on 7.1.x know what to expect out of a patch level release and will need to understand that to get any new features available, they will have to upgrade to the next minor release version.
Thanks, Steven On 2/7/18, 3:52 PM, "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? I imagine if we change policy to #1 above, we’ll merge all these into v7.1.3 or v7.1.4. — leif