I prefer #2. If we started backporting new features to 7.1.x branche, the branch would be something like another master that doesn't break compatibility, which means it'll be unstable all the time.
I'd like to hear opinions from people who supports #1. What we need to discuss might not be "which version" but "when", if the reason for #1 is delivery speed. We don't have clear criteria for minor releases. -- Masakazu On Fri, Feb 9, 2018 at 4:31 AM, Derek Dagit <der...@oath.com.invalid> wrote: > +1 (non-binding) for #2 > > Steven's description seems reasonable to me also. > > On Thu, Feb 8, 2018 at 11:26 AM, Bryan Call <bc...@apache.org> wrote: > > > +1 - well said > > > > I prefer #2. > > > > -Bryan > > > > > On Feb 7, 2018, at 7:20 PM, Masaori Koshiba <masa...@apache.org> > wrote: > > > > > > Hi, > > > > > > It looks like #1 violate the Semantic Versioning(*1) which we're > > following > > > now. Do we really stop following the versioning? > > > IMO, we should keep following it, becasue it's easy to indicate that > new > > > release has only bug fixes, new features, or incompatible changes. > > > > > > I prefer #2 and we should release 7.2.x if we want to add new features > to > > > 7.x series. > > > > > > *1 : [Semantic Versioning 2.0.0](https://semver.org) > > > > > > Thanks, > > > Masaori > > > > > > 2018年2月8日(木) 4:52 Leif Hedstrom <zw...@apache.org>: > > > > > >> > > >> > > >>> 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 > > >> > > >> > > >> > > > > > > > -- > Derek >
