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