If we have to decide on the date, we need to get confirmation on the following which I mentioned earlier. We dont want to freeze things and no one to make progress on
1. Who can sign up for fixing the tests(including upgrade tests). I don't think we can release without tests passing. We can still cut alpa 2. Who can sign up for testing the alpha1. I know Ben has shown interest. Who else can do it and when? We need to know this so we dont cut a release and wait for people to start testing it. 3. Who has cycles to fix the bugs which will come out of testing. When to freeze should be decided when we know what timeline the contributors come up with for the above three points. Thanks, Sankalp On Wed, Apr 11, 2018 at 10:07 AM, Ariel Weisberg <ar...@weisberg.ws> wrote: > Hi, > > What is the role of minor releases in Cassandra? I know that we have > guarantees we make about minor releases that we don't make about major > releases (is this summarized anywhere?), but is there anyone who actually > thinks those guarantees are worth it vs having major releases on a shorter > schedule? > > If we had major releases on a shorter schedule they would be smaller and > stabilize faster and I think that has already been brought up. > > We don't do calendar based releases and I think that's a mistake. Maybe we > don't cut the final version of a release based on the calendar, but I think > we should release branch on a fixed cadence and release when ready. > > I also don't see a place for minor releases as they exist today. It seems > like they are almost all the overhead of a major release with unnecessary > restrictions on what is possible. > > Ariel > > On Wed, Apr 11, 2018, at 12:42 PM, Ben Bromhead wrote: > > I'm on the side of freezing/branching earlier so we can really start the > QA > > process, but I do understand the concerns. > > > > As Kurt alluded to previously, given our current release velocity, > 4.1/5.0 > > will likely be some time away after 4.0. If we manage to release two high > > quality stable major versions back to back in a span of say 12 months, > that > > would actually be pretty awesome. The upgrade cycle will be a minor > > complaint for just those major versions as the community settles on a > > better cadence as we learn and go through it. > > > > Both Kurt and Jeff have advocated for key features that should be part of > > the next major update which seems to be a major part of the desire to > push > > back against an early feature freeze. Interestingly most of these > > contribute to the theme of the release (stability) even though they are > > large changes. Particularly: > > > > https://issues.apache.org/jira/browse/CASSANDRA-9754 - "Birch" (changes > > file format) > > https://issues.apache.org/jira/browse/CASSANDRA-10540 - > RangeAwareCompaction > > https://issues.apache.org/jira/browse/CASSANDRA-13426 - Idemponent > schema > > changes > > > > We haven't seen any actual binding -1s yet on June 1, despite obvious > > concerns and plenty of +1s > > > > Having said that, the above issues are the only ones people have > identified > > as: > > > > - the issues is a desired feature, > > - the issue has clear progress on the tickets, > > - the issues fits the theme of the release, and > > - there is some concern about the issue making the June 1 deadline. > > > > I would invite those working on / reviewing these tickets to comment > (Michael > > Kjellman, Marcus Eriksson, Aleksey Yeschenko) specifically about > inclusion > > into 4.0 and June 1. > > > > If we want to delay the feature freeze for these, either a June 1 freeze > > with a carve-out/exception for those three (they can get committed after > > June 1 to 4.0) or a moderate push back of the freeze date (e.g. July 1) > may > > be an appropriate compromise. > > > > The carve-out/exception however is messy and opens a can of worms on the > > proposed testing process for a 4.0 branch, but it is an option. > > > > I know this list doesn't include changes like transient replicas and > > strongly consistent schema changes (previously mentioned), but the state > of > > the tickets is still in an architectural discussion, so I don't think its > > worth making them blockers. Pluggable storage was also raised as > something > > worth including for 4.0, if someone working on those (Dikang, Blake?) had > > an opinion on it regarding 4.0, impact on stability and a June 1 > deadline? > > > > Ben > > > > > > On Wed, Apr 11, 2018 at 11:15 AM Blake Eggleston <beggles...@apple.com> > > wrote: > > > > > I agree that not releasing semi-regularly is not good for the project. > I > > > think our habit of releasing half working software is much worse > though. > > > Our testing/stability story is not iron clad. I really think the bar > for > > > releasing 4.0 should be that the people in this thread are running the > code > > > in production, recommending their customers run it in production, or > > > offering and supporting it as part of their cloud service. > > > > > > In that context, the argument for waiting for some features is less > about > > > trying to do all the things and more about making 4.0 something worth > the > > > time and expense of validating for production. > > > > > > On 4/11/18, 1:06 AM, "Sylvain Lebresne" <lebre...@gmail.com> wrote: > > > > > > On Wed, Apr 11, 2018 at 12:35 AM Jeff Jirsa <jji...@gmail.com> > wrote: > > > > > > > Seriously, what's the rush to branch? Do we all love merging so > much > > > we > > > > want to do a few more times just for the sake of merging? If > nothing > > > > diverges, there's nothing gained from the branch, and if it did > > > diverge, we > > > > add work for no real gain. > > > > > > > > > > Again, to me, the "rush" is that 1) there is tons of changes > sitting in > > > trunk > > > that some user (_not all_, granted)[1], especially new ones, would > > > likely > > > benefits, and sooner for those is better than later, 2) we want to > > > favor > > > release stability and we *know* from years of experience (and > frankly, > > > common > > > sense) that the bigger the release is, the harder it is to test > > > it/ensuring > > > overall stability[2] and 3) not having major releases for years[3] > is > > > impacting at least the perceived dynamism/liveness of the project > to > > > external > > > actors (prospective new user come in mind here, but not only) and > > > that's > > > simply bad for the project. > > > > > > And having listed arguments for a soon freeze/not accumulating much > > > more > > > before release, I'd like to reverse the question to you: what are > the > > > big > > > downsides of not doing that? Are we really that hung up on our own > > > developers > > > comfort that the annoyance of a bit more merging trumps the > arguments > > > above? > > > > > > Anyway, the reasons above make me thing that it's better _for the > > > project_ > > > to freeze 4.0 soon, which doesn't exclude a "short" cycle for the > > > following > > > major (where my definition of short here is something like 6-8 > > > months), and > > > I'm happy to decide to make 4.0 a non-mandatory upgrade to whatever > > > comes next so that folks that prefer upgrading rarely can simply > skip > > > it and > > > go to the next one. Likely nobody will die if we wait more though, > and > > > it's > > > clear it will make a few people here more happy if we do, but I > > > believe the > > > project as a whole will be a bit worst off, that's all. > > > > > > -- > > > Sylvain > > > > > > > > > [1]: I'll note that I don't deny upgrading is huge deal for some > > > users, but > > > let's not skew arguments too much based on any one user interest. > For > > > many > > > users, upgrading even every year to get improvements is still > > > considered as > > > a > > > good deal, and that's not counting new users for which it's super > > > frustrating > > > to miss out on improvements because we release major only every 2+ > > > years. > > > [2]: I'll be clear: I will simply not buy anyone argument that > "we'll > > > do > > > so much better testing this time" on face value. Not anymore. If > you > > > want to > > > use that argument to sell having bigger releases, then prove it > first. > > > Let's > > > do reasonably sized 4.0 and 4.1/5.0 and prove that our > > > testing/stability > > > story > > > is iron clad now, and then for 4.2/6.0 I'll be willing to agree > that > > > making > > > bigger release may not impact stability too much. > > > [3]: Conservative estimate, if we do care about stable releases as > we > > > all > > > seem > > > to, even if we were to freeze June 1, we will almost surely not > release > > > before > > > October/November, which will be ~1.3 year since the last major > release > > > (again, > > > that's the conservative estimate). If we push a few months to get > some > > > big > > > complex feature in, not only this push the freeze of those few > months, > > > but > > > will also require more testing, so we're looking at 2+ years, with > a > > > possibly > > > large '+'. > > > > > > > > > > > > > > > > > > > > Beyond that, I still don't like June 1. Validating releases is > hard. > > > It > > > > sounds easy to drop a 4.1 and ask people to validate again, but > it's > > > a hell > > > > of a lot harder than it sounds. I'm not saying I'm a hard -1, > but I > > > really > > > > think it's too soon. 50'ish days is too short to draw a line in > the > > > sand, > > > > especially as people balance work obligations with Cassandra > feature > > > > development. > > > > > > > > > > > > > > > > > > > > On Tue, Apr 10, 2018 at 3:18 PM, Nate McCall <zznat...@gmail.com > > > > > wrote: > > > > > > > > > A lot of good points and everyone's input is really > appreciated. > > > > > > > > > > So it sounds like we are building consensus towards June 1 for > 4.0 > > > > > branch point/feature freeze and the goal is stability. (No one > has > > > > > come with a hard NO anyway). > > > > > > > > > > I want to reiterate Sylvain's point that we can do whatever we > > > want in > > > > > terms of dropping a new feature 4.1/5.0 (or whatev.) whenever > we > > > want. > > > > > > > > > > In thinking about this, what is stopping us from branching 4.0 > a > > > lot > > > > > sooner? Like now-ish? This will let folks start hacking on > trunk > > > with > > > > > new stuff, and things we've gotten close on can still go in 4.0 > > > > > (Virtual tables). I guess I'm asking here if we want to > > > disambiguate > > > > > "feature freeze" from "branch point?" I feel like this makes > sense. > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > > > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > > > -- > > Ben Bromhead > > CTO | Instaclustr <https://www.instaclustr.com/> > > +1 650 284 9692 > > Reliability at Scale > > Cassandra, Spark, Elasticsearch on AWS, Azure, GCP and Softlayer > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > >
