Re: Roadmap for 4.0
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
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
On Thu, Apr 12, 2018 at 3:58 AM kurt greaves <kurt@xxxxxxxxxxxxxxx> 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
> Not to mention the total lack of any kind of standard performance testing