> I'd like to see pluggable storage and transient replica tickets land, for > starters.
So after all the fuss and scandal about incremental repair and MV not stable and being downgraded to experimental, I would like to suggest that those new features are also flagged as experimental for some time for the community to use them extensively before being promoted as first class features Thoughts ? On Mon, Apr 9, 2018 at 11:36 PM, Jeff Beck <beckj...@gmail.com> wrote: > 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 > > > > > > > > > > > > > >
