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 > >
