I feel this discussion is starting to go in every directions and getting farther away from any decision/progress so I'll attempt to summarize what I hear, where I stand and *more importantly*, why.
So as far as "what do we do for 4.0", I hear it boil down to 3 options: 1) we freeze June 1. It says nothing on when we do release but starting testing early, which also by extension limit the scope of what needs to be tested, give believability in an earlier and more stable release. Everyone seems to agree stability is good, and having no major release for too long run the risk of everyone outside our own bubble thinking the project is dead. 2) we decide on a freeze date now, but later than June 1 (the question is then "when?"). I'm listing this because there has been some explicit "+1 to freezing but not June 1" but I'll admit I'm not entirely sure of the reasoning behind this, and if there has been explicit argument for this, I've missed them. 3) we don't decide on a freeze date, 4.0 freeze is feature related. So we build a list of features that needs to be in to freeze (which can have some color for sure, some may be harder requirements than others). The best argument I've heard for this is Blake's one, which is that people won't truly test the release unless it is sexy (implying trunk isn't at all right now) and that it would therefore yield more stability. I'll acknowledge that some have expresses a preference for a freeze earlier than June 1, but I think those are fine with June 1 as well so I think we can fold this into option 1 to simplify. I also suspect option 2 was really meant as option 3, but with some deadline to avoid slipping too much (but without really changing the main intent), so maybe the initial question is really just option 1 versus option 3 (and we decide the details of option 3 if we can agree this is what we want). As should be clear, I'm a proponent of 1 for the reasoning I expressed on that point. I don't deny there is some logic behind the "it needs to be sexy to be tested" argument for 3, but it's simply imo more risky, and too much so. And this because: 1) I'm convinced it will delay the release *a lot* in practice compared to option 1 and I think we're underestimating the damage not releasing a major for years will do to the project. 2) it's all predicated on people doing unprecedented level of testing that they wouldn't do if we go with option 1, but there is no historical evidence to support the notion that it is a safe bet. If this doesn't happen, which we *have* to consider, then the project will be in a *much* worst state than with option 1. We'll have taken forever to release a less stable release. -- Sylvain On Thu, Apr 12, 2018 at 3:58 AM kurt greaves <k...@instaclustr.com> wrote: > > > > 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. > > Yeah this, I've never heard of anything that we don't do in "minors", and > it seems to me that everyone treats the minors as majors (hell, we're doing > that here re 4.1). It seems to me that we should just have <major>.<patch> > versioning based on the way we treat minors. > > Who can sign up for testing the alpha1. I know Ben has shown interest. > > We can certainly do it, and we plan to do a lot of testing of 4.0, but I > doubt we'll have anything ready to properly test it by June 1st. > Another thing worth noting is dtests currently only partially run on > CircleCI and it seems to me that Apple is the only one that actually runs > them even there. It's going to take us a while to get the testing > environment in a state that covers all bases post-freeze, and it's a good > idea to have some commitment to doing that before we go ahead and freeze. I > agree there's little point freezing if we can't even test the system > properly. > > Not to mention the total lack of any kind of standard performance testing > environment... > >
