We should assume that we’re ditching tick/tock. I’ll post a thread on 4.0-and-beyond here in a few minutes.
The advantage of a prod release every 6 months is fewer incentive to push unfinished work into a release. The disadvantage of a prod release every 6 months is then we either have a very short lifespan per-release, or we have to maintain lots of active releases. 2.1 has been out for over 2 years, and a lot of people (including us) are running it in prod – if we have a release every 6 months, that means we’d be supporting 4+ releases at a time, just to keep parity with what we have now? Maybe that’s ok, if we’re very selective about ‘support’ for 2+ year old branches. On 11/18/16, 3:10 PM, "beggles...@apple.com on behalf of Blake Eggleston" <beggles...@apple.com> wrote: >> While stability is important if we push back large "core" changes until >> later we're just setting ourselves up to face the same issues later on > >In theory, yes. In practice, when incomplete features are earmarked for a >certain release, those features are often rushed out, and not always fully >baked. > >In any case, I don’t think it makes sense to spend too much time planning what >goes into 4.0, and what goes into the next major release with so many release >strategy related decisions still up in the air. Are we going to ditch >tick-tock? If so, what will it’s replacement look like? Specifically, when >will the next “production” release happen? Without knowing that, it's hard to >say if something should go in 4.0, or 4.5, or 5.0, or whatever. > >The reason I suggested a production release every 6 months is because (in my >mind) it’s frequent enough that people won’t be tempted to rush features to >hit a given release, but not so frequent that it’s not practical to support. >It wouldn’t be the end of the world if some of these tickets didn’t make it >into 4.0, because 4.5 would fine. > >On November 18, 2016 at 1:57:21 PM, kurt Greaves (k...@instaclustr.com) wrote: > >On 18 November 2016 at 18:25, Jason Brown <jasedbr...@gmail.com> wrote: > >> #11559 (enhanced node representation) - decided it's *not* something we >> need wrt #7544 storage port configurable per node, so we are punting on >> > >#12344 - Forward writes to replacement node with same address during replace >depends on #11559. To be honest I'd say #12344 is pretty important, >otherwise it makes it difficult to replace nodes without potentially >requiring client code/configuration changes. It would be nice to get #12344 >in for 4.0. It's marked as an improvement but I'd consider it a bug and >thus think it could be included in a later minor release. > >Introducing all of these in a single release seems pretty risky. I think it >> would be safer to spread these out over a few 4.x releases (as they’re >> finished) and give them time to stabilize before including them in an LTS >> release. The downside would be having to maintain backwards compatibility >> across the 4.x versions, but that seems preferable to delaying the release >> of 4.0 to include these, and having another big bang release. > > >I don't think anyone expects 4.0.0 to be stable. It's a major version >change with lots of new features; in the production world people don't >normally move to a new major version until it has been out for quite some >time and several minor releases have passed. Really, most people are only >migrating to 3.0.x now. While stability is important if we push back large >"core" changes until later we're just setting ourselves up to face the same >issues later on. There should be enough uptake on the early releases of 4.0 >from new users to help test and get it to a production-ready state. > > >Kurt Greaves >k...@instaclustr.com
smime.p7s
Description: S/MIME cryptographic signature
