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.


On Mon, Apr 9, 2018 at 1:46 PM Nate McCall <> 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:
> For additional commands, e-mail:

Reply via email to