RFC: Focus only on the 4-year-supported major releases

[sminnee]

Ingo and I have had a few discussions about SS5 we're unsure that pushing for an SS5 release in the next couple of months is of much value.

We had slated SS5 as a non-LTS release in October, but outside a few sundry contributions there has been little effort on the master branch. The SSLtd teams that are assigned to work on OSS have been put all their energy into 4.x releases, so that users can benefit from this work more promptly.

We’ve come a few conclusions:

• The community is relatively early in the “upgrade to SS4” cycle, and foisting another major release on people isn’t going to provide much stability. Although this is definitely true for larger or more risk-averse organisations, it's also true of a lot of smaller organisations. At meetups, for example, we've still meet a lot of people trying SS4 for the first time, and feedback that we should have at least 2 years of overlap in our LTS releases came from a range of organisations, big & small.

• Semver / LTS is basically a statement of “how often are you going to cause painful upgrades for your users?” I think it’s in everyone’s interests to keep this occasional. The current timeframe of the LTS releases (2 years apart, 2 years overlap) is a good support timeframe for most users.

• There’s a huge benefit to putting as many features into minor releases as we can, and it’s worth the extra effort to do this. Specifically, the benefit is that more users will adopt these features more promptly. Our recommendation in #8257 ties closely to this.

• The ecosystem doesn't live on the bleeding edge. Although we've made good progress in this area, a lot of modules are yet to be upgraded to SS4. If we released SS5 now, anyone jumping on board would have to upgrade any module themselves, which is a huge hassle. Asking module maintainers to produce both an SS4 and SS5 version would be painful.

All this means that there are very few users that would benefit from an SS5 release in the near future. So my recommendation has a few parts:

Stable releases are LTS releases

This recommendation means:

• we remove the current SS5 release from the timeline
• relabel SS6 as SS5 (for October 2019)

Essentially this means that all our major releases follow our LTS support durations. I acknowledge that this calls into question the meaningfulness of an LTS label, but I see that as a secondary detail. I'd be comfortable with dropping the LTS language from the roadmap document, I think the most important thing are the durations.

If we were to do this, one use-case that we drop is the ability to get early stage feedback from a small group of users that are happy to jump through the hoops of early adoption. How might we approach that? With the next 2 parts of this RFC's recommendation:

Put interesting new stuff in optional modules wherever possible

In general, I think that SilverStripe is still more monolithic than is ideal, and radical new features could be provided as an optional module. This should be our first port-of-call for making a massive change. For example, a reactpages module would make sense as a way of providing a pure-react based alternative to CMSMain. This also means that you don't need to delete CMSMain before you get started, and so it's easier to use prior to having feature-parity with CMSMain.

Release alphas as soon as there are interesting changes in master

Not everything will be able to be done as a separate package, and so changes to master will be necessary. To put this out to the community, I recommend that we tag alpha releases from an early stage, basically as soon as there were some meaningful changes in the master branch.

Getting people to use alpha releases on their site would necessitate that we don't use "alpha" as an excuse for "everything is broken". Instead, alpha releases would end up being more a statement that APIs might change radically before the next release.

This might seem like a straightjacket, but the benefit would be that it avoids the risk of us being unable to release because master is still completely broken. "Break everything and the rebuild it" is a dangerous game that is the antithesis of an agile approach.

We could think about how we might encourage people to use alpha releases in production, such as a special "alphas-in-prod" support forum/slack, that people working on master keep an eye on, to get feedback and provide support.

UPDATE 3 Sept: Focused on regular alphas as a way of engaging with early adopter community.

[chillu]

Needs feedback from @silverstripe/core-team.

[kinglozzer]

The community is relatively early in the “upgrade to SS4” cycle, and foisting another major release on people isn’t going to provide much stability.

Agreed

The current timeframe of the LTS releases (2 years apart, 2 years overlap) is a good support timeframe for most users.

Agreed, but it begs the question of why bother with non-LTS releases at all?

• Upgrading existing projects: how many are going to do this so soon after SS4, without the bonus of LTS? Why would anyone who hasn’t already upgraded from 3 -> 4 skip straight to 5? My point is I don’t see it being an upgrade path that many people will take
• New projects: with support ending relatively quickly, how many projects are going to go to the effort of upgrading to 6? Like it or not, we’ll always end up with a large number of sites that stay on whatever major release they were built on. Given that, it makes more sense IMO to support every major release for longer, even if that means less frequent major releases.

If we released SS5 now, anyone jumping on board would have to upgrade any module themselves, which is a huge hassle. Asking module maintainers to produce both an SS4 and SS5 version would be painful.

I think the other side-effect of frequent non-LTS releases is that we’re effectively asking module maintainers to support at least 3 major versions of SilverStripe. If we released SS5 in October, module authors might find themselves supporting 3, 4 and 5 all at once. Throw SS6 into the mix before 3.x LTS support has ended and that means even more headaches. It also makes it harder to release new major versions of modules - if 1.x supports 3, 2.x supports 4, and 3.x supports 5, what happens if the author needs to make a breaking change to the version supporting SS4?

Encourage people to use master

I agree that early/more alphas would be a better approach than this - people are (rightly) more averse to running dev-master. We also occasionally end up in a state where a change in one module temporarily breaks another, using tagged alphas would help prevent people pulling in code in that state.

[robbieaverill]

...that we don't use "alpha" as an excuse for "everything is broken". Instead, alpha releases would end up being more a statement that APIs might change radically before the next release.

Yeah, I'd like to think that we can say that now, but you're right.

Encourage people to use master

I'd much rather release lots of alphas as you suggested.

Put lots of interesting new stuff in optional modules

+1 - I think this is going to be key to shaping the future landscape of SS4 and preparing people for the defaults of SS5. I'm also mildly wary of replacing something with an optional module by default then not testing it any more and having bugs come up with it - ensuring our CI suites cover all the supported possibilities would help to alleviate this though.

[chillu]

Thanks for the thoughtful feedback as usual, @kinglozzer :) I've always regarded non-LTS releases as an opportunity for dedicated teams with a long-term investment into keeping a codebase updated to use cutting edge APIs, while still providing a stable authoring experience. On the kind of websites which have steady resourcing and a well managed approach to tech debt - "products" rather than "projects". Even though that's the minority of SilverStripe websites and apps, it's an important minority, and a good opportunity to get buy-in from developers early by having them run changed APIs in production. Without a more frequent non-LTS, we'd only be changing APIs every few years. But as Sam outlined, in some cases we can run "parallel APIs" instead of changing existing ones (e.g. different modules). Or release modules quicker than core (e.g. silverstripe/graphql).

[sminnee]

If I understand Loz's point correctly, he's advocating to only have major releases every 2 years, each of which is supported for 4 years (i.e., our LTS releases). This is something that I agree with.

I think that the most likely way out of that that would be in the users' interests is if the upgrader tools were improved to the point that major release upgrade was a small piece of work.

I've always regarded non-LTS releases as an opportunity for dedicated teams with a long-term investment into keeping a codebase updated to use cutting edge APIs, while still providing a stable authoring experience.

Do we have any evidence of this that wouldn't be met by alpha / master releases?

[chillu]

Do we have any evidence of this that wouldn't be met by alpha / master releases?

I think it's viable to achieve that. The closer the changed/new APIs get to the authoring experience (e.g. GraphQL, React, LeftAndMain) without a parallel UI implementation, the harder it'll be to keep this stability. But it's a worthy goal that we already strive for by having end-to-end tests on master.

[sminnee]

Yeah we had a notable user working from alpha/master releases for SS4, and I think we could improve on the stability of the SS5 releases. Incremental changes, rather than a big bang "let's do it right this time"

[sminnee]

I've updated the wording of the RFC to focus on alpha releases rather than recommending people use master, since there's been a clear preference for that in the initial comments.

[kinglozzer]

I'm also mildly wary of replacing something with an optional module by default then not testing it any more and having bugs come up with it

That’s a good point, we’re effectively doubling our support efforts on a specific feature if we have two implementations of it. I don’t think that should block that approach, but it’s worth bearing in mind - I wouldn’t want to reach a point where the resolution of an issue ticket is “use module X instead, it works there”.

I've always regarded non-LTS releases as an opportunity for dedicated teams with a long-term investment into keeping a codebase updated to use cutting edge APIs, while still providing a stable authoring experience.

Yeah I think you’re right, I failed to consider that end of the market but if we can get that buy-in it probably does provide more thorough testing than the “projects” end. Hopefully earlier alphas can support that

If I understand Loz's point correctly, he's advocating to only have major releases every 2 years, each of which is supported for 4 years (i.e., our LTS releases).

Correct :)

[chillu]

@silverstripe/core-team I'd like to announce this on silverstripe.org/blog this week. If you have major concerns on this direction (and consequently put up your hand to significantly contribute to preparing/releasing/maintaining a 5.x earlier than proposed), please raise them in the next 24h.

[maxime-rainville]

Seems like there's no outstanding points left to discuss on this issue. Can we close it?

If not, can we identify clear next steps or outstanding questions left to resolve?

[chillu]

Yeah been announced on https://www.silverstripe.org/blog/update-on-silverstripe-5-x/