If you are going to make 4 bigger as long as we call out that 3.11.x (or whatever) will keep getting patches for stability only that's all that's needed. We haven't gone to 3.x releases many places yet as we wait for a release that will be stable longer. Knowing 4 is going to be bigger I wouldn't want to see more feature releases in 3.x
I wouldn't want to greatly slow features down if they require a major release and 5 is too far off. Jeff On Mon, Apr 9, 2018, 4:05 PM Josh McKenzie <jmcken...@apache.org> wrote: > > > > If they're not close to finished now why even consider them for the 4.0 > > release? > > Merging in major features at the end of a release cycle is not the path to > stability, imo. > > On Mon, Apr 9, 2018 at 4:56 PM, Jonathan Haddad <j...@jonhaddad.com> wrote: > > > There's always more stuff to try to shoehorn in. We've done big releases > > with all the things, it never was stable. We tried the opposite end of > the > > spectrum, release every month, that really wasn't great either. > Personally > > I'd be OK with stopping new features by the end of this month and aiming > to > > release a stable 4.0 when we agree we would be comfortable dogfooding it > in > > production at our own companies (in a few months), and aim for 4.1 (or > 5.0 > > I don't want to bikeshed the version) for pluggable storage and transient > > replicas. If they're not close to finished now why even consider them > for > > the 4.0 release? They're so core they should be merged into trunk at the > > beginning of the cycle for the follow up release in order to get as much > > exposure as possible. > > > > Jon > > > > On Mon, Apr 9, 2018 at 1:46 PM Nate McCall <zznat...@gmail.com> wrote: > > > > > > I'd like to see pluggable storage and transient replica tickets land, > > for > > > > starters. > > > > > > I think both those features are, frankly, necessary for our future. On > > > the other hand, they both have the following risks: > > > 1. core behavioral changes > > > 2. require changing a (relatively) large surface area of code > > > > > > We can aim to de-risk 4.0 by focusing on what we have now which is > > > solid repair and NIO internode (maybe we move the 4.0 branch timeline > > > up?), aiming for a 4.1 following soon-ish. > > > > > > Or we can go in eyes open and agree on a larger footprint 4.0. > > > > > > I'm on the fence, tbh (can't emphasize enough how big both those > > > features will be). I just want everyone to know what we are getting > > > into and that we are potentially impacting our goals of "stable" == > > > "exciting." > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > > > > > >
