Support Timeline and LTS (draft)

[Ingo Schommer]

Hello everyone,

the core team has been discussing how we plan to support SilverStripe core releases going forward, and strike a balance between speed of innovation for SilverStripe core, and stability for everyone's clients.

Sam has created a support timeline (draft) which we're putting up for discussion here. The dates mentioned in the "provisional plan" section are a guideline only. We'll publish this timeline in our open source documentation once it's firmed up.

Summary:

- Only applies to SilverStripe core (not all supported modules)

- From version 3.2 and onward, we support major versions for longer periods of time, and we regularly release minor versions on each of these that are supported for shorter periods

- From version 3.2 onward, we are following Semantic Versioning, which make minor release upgrades (e.g. from 4.1 to 4.2) as painless as possible.

- From version 4 onward, we mark some releases as "LTS" (Long-Term Support). We recommend that customers seeking multi-year stability make use of LTS releases.

- LTS versions relate to a release line (4.x) rather than a specific minor release

So you can have the same SemVer stability expectations for non-LTS major releases, but they'll be supported for a shorter time. So if you upgrade to 5.0.0 on the day it's released, you need to be prepared to upgrade to 6.x in less than two years.

This document is an outcome of many conversations with clients and partners. It reflects expectations for a mature software product. We're interested in hearing your own experiences with supporting SilverStripe projects, and gain insights into your own clients expectations.

Please remember that this is a commitment by the entire SilverStripe community: By maintaing more release lines, we tend to have less time for new feature development. Hence we're relying on the community to drive this stability initiative together with the core team, e.g. by sending bugfix pull requests to older release branches, helping with bug triage, etc.

Thanks

Ingo & SilverStripe Core Team

[David Alexander]

Very happy to see this! 

Quick thoughts:

(1) I am building sites now in 3.4 so it is REALLY nice to see the commitment to releasing a 3.5 with support for it going out until the end of 2018, otherwise there would have to be an uncomfortably rapid upgrade from 3 to 4 to 

stay within a support window (by the way, 3.5 is after 4.x in the spreadsheet - perhaps this should be reversed? I had an initial shock seeing 4.x following 3.4 and hence thinking 3.4 is the last in the 3 line and support ending in March! But then I saw 3.5 in the next table...Phew....).

(2) I was wondering if you might consider extending the 4 year LTS cycle to a 5 year one by extending the last phase of limited support an extra year. This change seems like it would only involve a relatively light increase in support commitment (since most problems will have been well and truly sorted by the start of the 5th year) but it may serve to significantly increase clients' comfort levels about investing in a long term SilverStripe solution.

Cheers,

D.

[Florian Thoma]

Love the idea!

[vikas srivastava]

LTS idea is awesome ! One of the reasons I always liked Ubuntu is there LTS releases after 2 years making me live peacefully for a while without long upgrade processes.

On Sat 3 Sep, 2016 10:19 am Florian Thoma, <floria...@innoweb.com.au> wrote:

Love the idea!

--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to silverstripe-d...@googlegroups.com.
To post to this group, send email to silverst...@googlegroups.com.
Visit this group at https://groups.google.com/group/silverstripe-dev.
For more options, visit https://groups.google.com/d/optout.

[Ingo Schommer]

Hello David, thanks for your feedback!

On Thursday, September 1, 2016 at 4:46:07 PM UTC+12, David Alexander wrote:

(1) I am building sites now in 3.4 so it is REALLY nice to see the commitment to releasing a 3.5 with support for it going out until the end of 2018, otherwise there would have to be an uncomfortably rapid upgrade from 3 to 4 to 

stay within a support window (by the way, 3.5 is after 4.x in the spreadsheet - perhaps this should be reversed?

The idea is that we'll have parallel release lines in different states of support - so potentially having a 3.5 in the 3.x release line after 4.0 in the 4.x release line is by design.

We can create minor releases in a release line while we're in "full support" for a release line (green lines). Once we go into "limited support" I'd expect patch releases only.

 

(2) I was wondering if you might consider extending the 4 year LTS cycle to a 5 year one by extending the last phase of limited support an extra year. This change seems like it would only involve a relatively light increase in support commitment (since most problems will have been well and truly sorted by the start of the 5th year) but it may serve to significantly increase clients' comfort levels about investing in a long term SilverStripe solution.

It's a tradeoff between where we spend our efforts - maintenance/stability vs. innovation/flexibility. I think if we're on the end of the 4th year, and significant parts of the community are still actively using a release line, we can discuss how LTS can be increased (e.g. a particular company actively contributing to testing and release efforts).

Ingo

[David Alexander]

Thanks for clarifying Ingo.

 

I think if we're on the end of the 4th year, and significant parts of the community are still actively using a release line, we can discuss how LTS can be increased (e.g. a particular company actively contributing to testing and release efforts).

​An eminently pragmatic approach, adapting to need. 

One last thought to throw into the mix: When reading the sentence "It is reasonable to assume that if a release is delayed, its entire support timeline is pushed forward." it appears you are proposing that if a release is delayed, its support timeline is pushed forward in such a way that none of the phases within the support timeline are shortened from what was initially scheduled. It occurred to me that it might be a good idea to further reassure people by (i) removing the "It is reasonable to assume" part of the sentence and (ii) stating a committment to retain minimum time durations for each phase much more explicitly (which also helps eliminate potential misunderstandings across languages). Some collection of statements like "Active Development will continue for no less than 12 months, Full Support will be provided for no less than 16 months,..." would do the trick, I reckon. I know for myself that it would be off-putting to jump into developing a site using an early LTS release only to hear, later, a surprise announcement that the Full Support and Limited Support phases were being halved in length, perhaps due to the LTS release being initially delayed, or some other reason.

Cheerio,

D.

[Sam Minnée]

Making commitments in the face of uncertainty is always a tricky business. I think that a more practical approach is probably to revise the timeline quarterly, and factor in any such adjustments.

With the support duration of 3.x, it will be hard to push it much beyond 31 Dec 2018 because that's when security support for PHP 5.6 ends. Upgrading to PHP 7.0 will also require an upgrade to SilverStripe 4. Now, if this became a showstopper you might come up with approaches for mitigating this, but it's not the kind of decision that we've want automatically triggered by a minimum support duration.

--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to silverstripe-d...@googlegroups.com.
To post to this group, send email to silverst...@googlegroups.com.
Visit this group at https://groups.google.com/group/silverstripe-dev.
For more options, visit https://groups.google.com/d/optout.

--

Sam Minnée

CEO

SilverStripe Limited

[Nic Horstmeier]

This is awesome! Even having this as a ballpark of what is intended is enough to pass give some sort of maintenance estimate to clients. This could also help community members anticipate where a PR may lie in respect to where a version may be in it's lifecycle.

Great work!

Nic

[Daniel Hensby]

As a core committer that contributes the majority in spare time (despite working for SS) - one of my main concerns is the number of release lines we support at a time. I'd like to see us supporting no more than 3 release versions at a time (which seems to be what this proposal is doing) - so it has my support on that line.

One concern I have is that we continue to develop actively on 4 even after it's released - shouldn't our effort be on forward thinking for 5, rather than BC compatible improvements for 4? We can leave bugs/improvements to the community whilst pushing forward with innovation.

Dan

[Sam Minnée]

I'd expect that by the time 4.0 comes out there will be a bunch of features that didn't quite make the cut that we'd like to get into an LTS release sooner than the end of 2019. So I think 1 or 2 minor releases where we focus on some backwards-compatible new features will be of benefit.

But perhaps in practise this will push out the time before which we start in earnest on SilverStripe 5? And perhaps we drop the emphasis on active development for 4.2, leaving only 4.1 (or 6 months rather than a year's effort, if you prefer)

--

You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to silverstripe-d...@googlegroups.com.
To post to this group, send email to silverst...@googlegroups.com.
Visit this group at https://groups.google.com/group/silverstripe-dev.
For more options, visit https://groups.google.com/d/optout.