[plan] Extend security support to cover the previous minor version of Drupal

Agreed on these points. We sites as new as 8.3 with contrib modules which were delayed in getting security fixes because of the incompatibilities. Security releases should be applied at least a few minor revisions back.

While the upgrade path seems to be worked on we are terrified of getting a security release on 8.4 and not having the ability to properly test our media and other modules. Layouts and other plugin had this issues with 8.2->.3 as well.

+1 from me on this. I work with several small organizations/NGOs, both as a freelancer and in my agency job, and it's been a real challenge to stay on top of these. Agreeing with all the points in the IS, but in particular want to underscore that because these smaller groups often don't want to try out RCs, the window really is very short.

Overall I've been really pleased with the release plan/schedule with D8, but I think this would be a reasonable tweak if it's something the security team feels like they could handle.

Note I opened #2945200: [policy, no patch] Four month minor release cycles about reducing release cycles to four months, which includes a two-minor-version support period. That has more discussion of the benefits and drawbacks of supporting two versions at a time.

+1 . I work at a non-profit with a very small team, and we need time to look at updates before doing the upgrade.

Because core adopts 2 minor release support, it means the security team will also have to support things longer for contrib. This gets very sticky pretty quickly. We're all volunteers, so asking a contrib module maintainer who is already pressed for time to do much support for older versions is asking a lot. So then we look at the security team. Adding workload to them is not super helpful. Or we just draw an abitrary line in the sand sand and "say" that 2 releases are supported. Overworked people trying to do more than they can or should, just waters down quality. So yes, you have "support" But who wants that quality of support? Not me. I'd rather have better support for 6 months than worse support and 12 months.

Being realistic, the "cost" of not needing to upgrade when 9.0 core is released is that you paid for all that by small, incremental upgrades every 6 months.

Get a process in place. Work on the process. Software moves fast. You cannot slow it down.

Why can't these sites with limited budget go without security support? If they are such a small budget, couldn't they just go unsupported?

@heddn They could, but they might opt instead to choose something other than Drupal where they won't be abandoned by security support so quickly.

@aleksip's points are well taken -- it may be true that the security team just can't take on this much workload. If so, so be it.

But I also agree that it would be nice to see some of the large enterprises and agencies willing to put some money/dev time into this.

Here's the "money quote" from @catch in the related issue summary:

This will require supporting two minor branches of Drupal 8 for security at a time, increasing the workload, although in practice we expect most security releases to only require cherry-picking changes between branches.

Because of the extensive test coverage in core (which is both a blessing and a curse), the idea that asking the security team to cherry pick a commit and let the test bots do their thing a few times a year would dramatically increase their workload is quite misleading. I used to be on the security team (from 4.7.x through 7.x days) and it *was* a crap ton of work, since we had no automated tests (and therefore no test bots) and team members had to manually do our best to "click through Drupal" on every new security patch to core. Times have changed tremendously. This policy change is *not* a *huge* burden on the security team.

Furthermore, while technically no one is getting paid by the Drupal Association to be on the security team, it is *quite* misleading to claim that they/we are "all volunteers". I'm calling BS. Most of the major Drupal shops have an obvious commercial interest in Drupal's security, and pay their employees to work on security team responsibilities. Again, times have changed.

I'm getting quite tired of the hypocrisy of claiming on the one hand that Drupal is entirely built and maintained by "volunteers" in the spirit of open source goodness, while simultaneously putting enormous barriers to entry (and retention) on the D8 user and contributor base so that "we" focus on supporting "ambitious sites" and The Enterprise(tm). Again, I'm calling BS. Please admit it: some huge companies with enormous resources are paying their employees to keep Drupal alive.

So, this request isn't about demanding that "volunteers" do a huge amount of extra work. It's asking the major shops that fund the security team to be willing to pay for an extra few days of total time a year to cherry pick a few commits, create release nodes, etc in exchange for not continuing to alienate and cut off what remains of the non-commercial user base of Drupal.

In any case, the issue described here affects all Drupal users, large and small.

This mirrors my experience as well. I've seen D8 production sites that are two or three minor releases behind, with teams of 5-10 dedicated developers and budgets to match. Small teams have trouble upgrading because they are waiting on contrib, while large teams have lots of custom code they need to verify. Not a single one of our clients has had a smooth experience with core minor releases, and I've seen firsthand how a (somewhat) justified fear of upgrades has led to a culture of not even attempting to upgrade at all.

I don't think extending security support to the previous minor is going to have a significant impact on upgrade adoption or costs. However, being stricter on compatibility promises would be a huge improvement and would help reduce the fear of Drupal upgrades we see in many developers.

For example:

There is a new experimental module replacing a contrib module, and the original contrib module is not supported in the new minor release.

This shouldn't happen and should be treated as a regression in core. If it can happen to a contrib module, it can happen to custom modules as well.

Also other contrib projects depending on this module might not have the resources to support two modules.

There's precedence for multiple releases in this all through Drupal's history, such as with Views 1 / 2. With moving contrib modules to core, it should be done in a way that doesn't collide with existing modules. For example, Media Entity can still work with Drupal 8.4. That lets sites do the core upgrade first (maintaining security support), and then do the module migration in between minor releases.

The new minor Drupal release might introduce major version updates for dependencies. Drupal 8.4 introduces Symfony 3.2 and jQuery 3.

It's been talked about in other issues, but this hit most of our clients and delayed their 8.4 deployment by weeks or months. In fact, many sites are still on 8.3.

Some changes in core are not considered BC breaking. This includes things like changing plugin constructors.

Perhaps we are at a time with core stability we can start following the Symfony BC guidelines and lock these things in for the 8.x cycle. #2550249: [meta] Document @internal APIs both explicitly in phpdoc and implicitly in d.o documentation seems like a good start.

Do you think extending security support should be pursued at all?

I think extending the security overlap period to two months from the current one month would be best. 4 weeks is not enough time for teams to test and deploy an upgrade, especially if they have fixed-date events during September or March they have to work around. One month puts a lot of pressure on tech managers, and once they've made the decision to not pursue an immediate upgrade, it tends to fall to the bottom of backlogs and be deprioritized in perpetuity. Two months is a lot easier to socialize as "required, but we have a reasonable amount of time to get upgraded".

Can you elaborate on this? If a contrib project decides to end support, for some reason or other, there does not seem to be much that core can do?

Ending support shouldn't mean the existing module stops working. Media Entity 1.x could be marked as unsupported, but I imagine it still works fine in Drupal 8.6.x (if core media is not installed).

Yes, ID and namespace collisions are hard, especially with annotations and entity types where there aren't effective namespaces. The same thing happens with Media; ideally, you should be able to have both media and media_entity enabled at the same time in 8.4, but you can't because they both have the same entity ID.

Could it be a policy that for any contrib modules moved to core, that either the core module has new unique IDs and machine names, or that contrib modules provide an upgrade path that frees up any IDs core wants to use?

I don't think modules moving into core is significantly different from what used to happen when contrib modules in Drupal 6 or Drupal 7 opened a new major branch (think Views 2 vs. Views 3). How smooth this is is going to depend on the module (and how integration into core is done) and seems like a completely separate discussion to security support.

The issue with additional security support for core is much less the security support for core - this in 99% of cases should be a cherry-pick, but that contrib modules need to work with two support minor releases for longer.

One of the hardest changes in core was the Symfony 2 to Symfony 3 update, but that was also essential for us to have security support from Symfony itself past the next year or so (and the main fallout was with drush rather than contrib modules as such) so while backwards compatibility and security support sometimes conflict, it's not possible to just pretend no tricky changes will ever need to happen.

I think supporting two branches of Drupal 8 core is more than just cherry-picking patches. There is still manual code review and a bit of testing involved (even if the patches do happen to turn out to be identical, which they aren't guaranteed to be). Personally I'd estimate this as a 10-15% increase in core security workload, compared to maybe a 30% increase for supporting three major branches (e.g. Drupal 6, 7, and 8) at once?

It's also worth noting that the security team already "semi-supports" two branches of Drupal 8 core today. The only official one is 8.4.x, but 8.5.x (i.e. the next unstable branch) gets partially supported too because Drupal 8 maintainers want the patches for that version ready to go before release, rather than deferring it to a critical public followup issue as was done in the past. So unless that changes, this proposal would be more like supporting three branches of Drupal 8 core at once, not two.

I also think it is worth asking whether there are other solutions to the problem this issue mentions, rather than assuming the proposed solution is the only one. For example, if the problem is that people are having trouble upgrading their sites within a short window every six months because Drupal 8 isn't backwards-compatible according to their expectations of what that term should mean (a problem which was actually predicted years ago..), then some other possible solutions could be any combination of the following:

1. Do Drupal 8 minor releases every 12 months rather than every 6 months, with a correspondingly longer release candidate phase.
2. Redefine what "backwards compatibility" means in Drupal 8 to be more strict (already discussed in some comments above).
3. Consider whether it's time to move Drupal 8 to long-term-support status and open Drupal 9 as the place where bigger/riskier changes can happen (not a real solution on its own since it would take some time to do, plus it would then bring up the even more difficult conversation of supporting Drupal 7/8/9 simultaneously... but Drupal 7 is over seven years old now and it's a conversation that will need to take place someday).

Also:

Most of the major Drupal shops have an obvious commercial interest in Drupal's security, and pay their employees to work on security team responsibilities.
....
So, this request isn't about demanding that "volunteers" do a huge amount of extra work. It's asking the major shops that fund the security team to be willing to pay for an extra few days of total time a year to cherry pick a few commits, create release nodes, etc in exchange for not continuing to alienate and cut off what remains of the non-commercial user base of Drupal.

I agree with the general thought and concern, but I'm not actually sure that's how most security work is currently funded.

For myself, as an example, I'm a very active member of the security team, but right now I don't get paid for doing it at all. And I think that a lot of people who work on security issues (including myself in the past) take some of the "community time" that their employers provide and use that for it. So yes, they're getting paid for the work, but indirectly - and it's at the cost of other activities that they could be using that time for (other kinds of contributions, reading tech blogs to keep up with the industry, whatever).

I think there are some shops that do fund security work more directly than the above, but I'm not sure it's a lot? It would be great if more did. But what you're talking about here might be more like "convince Drupal shops to fund security team work even though they never did before" rather than convincing them to slightly increase their existing funding.

Do Drupal 8 minor releases every 12 months rather than every 6 months, with a correspondingly longer release candidate phase.

There's a proposal for a four month cycle linked from this issue, because we already have issues with incorporating Symfony security updates, new PHP releases, occasional critical bugs that are potentially disruptive and have to be kept out of patch releases. A one year cycle would put more pressure to incorporate some of those changes into patch releases, making patch releases potentially more risky. For example contrib modules are sometimes blocked on a stable release by a core bug/limitation, leaving them out of security support for longer.

Redefine what "backwards compatibility" means in Drupal 8 to be more strict (already discussed in some comments above).

The most disruptive changes we've had recently:
- Symfony 3 update - was required for security support in the medium-long term and very unlikely we'll do Symfony 4 until Drupal 9.
- core deprecation testing, ironically required to be stricter/clearer about our backwards compatibility policy.

It's always possible to discuss specifics of the bc policy, but unless someone can identify a class of changes that usually cause problems for contrib and a solution to avoid them, it's not very concrete - we do regularly make adjustments if we think we can make things smoother.

Consider whether it's time to move Drupal 8 to long-term-support status and open Drupal 9 as the place where bigger/riskier changes can happen (not a real solution on its own since it would take some time to do, plus it would then bring up the even more difficult conversation of supporting Drupal 7/8/9 simultaneously... but Drupal 7 is over seven years old now and it's a conversation that will need to take place someday).

There's an extra reason this isn't a solution at all, in that we're planning a 6 month cycle for Drupal 9 with a continuous upgrade path (only dropping bc layers/deprecations), then staying on a similar patch/minor release cycle that we have on 8.x. So it would allow a particular set of disruptive changes to happen, but only once before we go to Drupal 10. Either way we can't do this until there is a fully stable Drupal 6/7-8 migration path, all this discussed in #2608496: [policy, no patch] Drupal 9 release timing and Drupal 7/8 EOL and related issues.

The idea behind opening Drupal 9 wouldn't be to solve this problem for people who choose Drupal 9 :) It would be to solve it for people who choose to remain on Drupal 8 (since Drupal 8 would then be in long-term-support status).

I've been spending the past few weeks at work doing interviews with various parties, trying to suss out Drupal 8 pain points and blockers to adoption.

Minor version upgrade pain is very prevalent out there, as is the fear of moving from one version to another without specifically budgeting a week or so to workaround whatever might blow up. The current release cycle gives site administrators about 6 weeks to do an upgrade, before they risk public disclosure of a security vulnerability. However, these minor versions often come with external library updates or moving contrib modules into core, which can cause cascading problems in tools (e.g. Drupal 8.4 and Drush), in contrib modules (e.g. I built my site using Workbench Moderation but now Content Moderation is stable in 8.5, what do I do now?), and in custom code. There's not been a single minor release of Drupal 8 that has not caused issues somewhere, and this is one of the primary issues leading to the general perception that "Drupal 8 isn't ready yet."

I'm pretty convinced that a proposal like this would have a massively positive impact on the Drupal 8 ecosystem as a whole, as it would extend that 6 weeks to more like 6 months (which is a far more reasonable amount of time to find that "troubleshooting" week), and would effectively give each Drupal 8 minor release a full year's worth of support, which would be an important marketing message to help offset negative perceptions out there.

So HUGE +1 from a "Drupal product manager" POV.

A proposal like this makes complete sense to me, as the Drupal developer community has been used to 2 major releases being supported for basically an LTS release cycle. The new Drupal 8 release cycle sounded great at first, but has been a big shock to our development team and our clients, as required updates typically would only happen when there were actually security advisories released for that major version. Any other version updates to core were optional in between advisories. Those previously optional updates have now basically become required, as the previous minor release is no longer supported. They also typically come without any actual threats known, and commonly add regressions for existing site features. This makes these updates extremely hard to explain to clients, especially clients who are used to the old release cycle.

Supporting 2 minor releases for Drupal 8 would at least feel a bit more normal in terms of longer term support for a previous version. It would also give development teams and contrib developers time to deal with getting updates done and fixing regressions in a reasonable amount of time on the amount of projects they may maintain. I've been working with Drupal for 10 years, but the current Drupal 8 release cycle would scare me away if I was starting with Drupal today. We need to make it easier to use Drupal, not harder, if we want to have more adoption in Drupal 8. We currently seem to be going the opposite direction on that scale.

tl;dr +1 from a developer who likes to keep Drupal sites secure.

Redefine what "backwards compatibility" means in Drupal 8 to be more strict (already discussed in some comments above).

Note that we're already continually evolving this. To date, most things perceived as BC breaks have been related to the following, starting with the most disruptive:

1. BC breaks in alpha experimental modules
2. Transitioning modules from contrib to core
3. Updating old/insecure versions of dependencies (jQuery 3 and Symfony 3 updates)
4. Actual security fixes or hardenings
5. Major/critical issues
6. Simple mis-estimation of how disruptive a change will be.

Here is what we have done and are doing to address each of these things:

• For #1, we changed our process so that alpha modules are no longer shipped in releases, so that will no longer be an issue.
• For #2, we continue to learn from the community's experiences. These changes are also somewhat necessary because the features we're moving into core are critical to the project. However, we can expect this to level off once we have beta-plus versions of the critical features in core and D8-to-D8 migrations for them. (E.g., the Media initiative has been doing some trailblazing in this area with a lot of investment into the ecosystem upgrade plan.)
• For #3, these are necessary and unavoidable. In the long term we plan to better synchronize our release cycle with Symfony's, PHP's, etc. and to potentially create new majors when we have to do a major version update of a major dependency, but the ecosystem is not ready for a D9 yet.
• For #4, these are also necessary. We put a lot of effort into making security fixes as BC as possible, but sometimes we need to break BC for something that is inherently insecure.
• For #5, these are often necessary as well. We weigh the impact vs. the disruption for each change. Sometimes we get it wrong and we continue to learn from experience in this area as well. Same goes for #6.

Edit: This issue is not the place to discuss the above more; we have other open issues for those things if anyone is interested. :) Just wanted to put this in more context.

All that said. I'm in favor of this change to security coverage for a number of reasons, not just related to concerns about minor version upgrade disruption:

• As David mentions, the D8 release cycle already requires having a fix ready for the development branch because we cannot have minor release blockers that might slip the release schedule. D8 releases are scheduled in advanced, not "when it's ready".
• Drupal 8 contributors and committers already expect to handle multiple minors within an issue and so don't even really blink.
• In past D8 SAs, most of the time the fix for two minors has been identical. About 10% of the time it is different between minors (either slightly different patches or different vulnerabilities between branches). There have only been a couple issues where the fix needed was substantially different.
• Most of the burden for tagging multiple releases is on D8 release managers, not the security team. We have created a new security release process to scale this burden as well as automated tools that make it easy to tag multiple releases at once.
• We already need infrastructural and core support for "equivalent" security releases for the current 6-week window when there is a critical issue (like SA-CORE-2018-002), as well as for the month before it where the new minor's RC receives security coverage. So it doesn't add much separate burden in this area either.
• Mixologic has also already done a lot of work on d.o infrastructure to make it easier for contrib to scale with multiple minor versions, as it's also something we need anyway regardless of security support.
• Many other projects have overlapping support cycles for minor releases, so people already expect it anyway even though we don't currently support it.
• In general, organizations tend to have yearly planning cycles corresponding to the fiscal or calendar year, not arbitrarily scheduled six-month cycles. So if we have a year's security coverage for a given minor, with overlap, that means sites can schedule their own minor version updates at whatever point works fro them and plan for it in advance. This makes releases more predictable and friendly to organizations generally.

BTW I also don't think contrib would necessarily need to support the previous minor. Core wouldn't be "supporting" it either, only releasing security patches. So the only actual need for more support would be when we have to do a coordinated security release with contrib. We've had a few of those but not too many.

(Aside: I missed "Database upgrade path issues, especially related to contrib" from #27, which would probably be in the list at #3. Dunno that we have a plan issue for that as a general problem space, unlike the others, but it is something we track in the release notes and with an issue tag every time we release a minor.)

Tagging this, since it's one of the things that came out of interviews under Dries's "Simplify Drupal" sub-initiative (findings to be discussed in the Nashville Driesnote).

BTW I also don't think contrib would necessarily need to support the previous minor. Core wouldn't be "supporting" it either, only releasing security patches.

If we could make this clearer, it would remove the main concern I have about this, which is people trying to run a 10 month old minor release with a brand new contrib module relying on APIs introduced in the next minor, and various similar situations like that.

The extra releases we did for SA-002 are for people who haven't updated anything since 8.3.x - which is presumably what people want to do, but not necessarily what official support for two branches will set expectations for.

Yeah re: #31, my plan was that we should make the update report, status report, annoying site update emails etc., present a warning to users when they are on an old minor, and an error when they are on a minor that is out of security coverage. The error could also be presented in the same dsm() as "security update requrired!" etc. Obviously we'll want UX review of all the specific things, but I've been planning to file issues for that for awhile and just not gotten around to it.

In general, I don't think people are going to try to update contrib but not core; from my own experience as a site owner, once you're in there doing updates and testing it on staging and etc., you might as well update everything that needs an update. (The one exception was when Views 2 and 3 broke everything and so we kept them on old versions, but that was the other way around: updating core but not contrib.)

I've been thinking about this again, and after seeing some more real-world D8 usage with our clients, I'm now in favour of supporting the previous minor. I really like the idea of specific warnings that you are on an old-but-supported minor release, instead of the supported / unsupported options we have today.

I think a key point is that contrib modules would need to start being explicit about declaring the minimum minor they support. For example, the docs on module info files make no mention of specifying a minor version for compatibility.

With an extended support period, would it make sense to be stricter about the SA backport policy? When discussing security support with non-technical stakeholders, there is a very big difference between "the Drupal security team provided the fix" and "we are easily able to backport it ourselves". Seeing the last SA be released for an unsupported 8.3.x tells stakeholders that they don't have to keep on a supported minor, because the security team will backport patches for highly-critical issues. "The other security issues fixed in 8.4 must not be important because the security team didn't bother with a backport". Perhaps a good middle ground for RCE SA's would be to provide patches (and not a full release) to make clear that the old release is not supported.

I think the title of this issue could be reworded to help us open our minds to more options and fresh ideas. I understand the goal here is to have some kind of Drupal 8.x LTS releases for site maintainers that don't need to live in the bleeding edge all the time.

I.e. why not: Restrict security support to even numbered releases (8.0, 8.2....) and make it last for one year? Just an example.

We are making the assumption that the only way forward here is to raise the burden on the security team and that is not true IMO.

Btw I would be even happier having less releases supported for a longer period, like one every two years.

In the meanwhile me, and it seems many other people too if you look at the adoption rates for D8, are good enough using latest Drupal LTS, also called Drupal 7.

What if every x point releases were marked as LTS? e.g. say 8.5, 8.10, 8.15 (or whatever; frequency open to debate) were marked as LTS? No new features would be added, but security patches would be backported until the end of Drupal 8.

Then sites that don't need new features could stay on those LTS releases indefinitely, while not becoming less and less secure as a result.

The jQuery breakages in 8.4 and the JSON endpoint breakages in 8.5 have made a lot of clients of mine really anxious about upgrading. "The site works fine; we don't need any new features, why upgrade?" If we can't ensure that point releases are actually going to have BC, then I think we should provide some kind of LTS, prior to 9.x being released, that sites can stay on.

My two cents.

and the JSON endpoint breakages in 8.5

Are you referring to #2937942: REST views: regression in 8.5.x: view with display using 'csv' format now returns a 406 response, need to add ?_format=csv to URL to make it work or something else?

Thanks @aleksip, I realize why I was confused at the beginning...

In the Driesnote slide this issue is listed under 'Security LTS'.

and yup, I landed here straight from the Driesnote (1:01:51), https://youtu.be/8HkOdpNT8Ec

So if the question here is "Extend security support...." or "Do you want the Security Team, to work more, for you, for free?", my answer is:

No, I don't. - And that anyway wouldn't fix the issue of contrib modules compatible with such version being supported longer, so we are back at square one.

What I'd like is some releases -they don't need to be too many, just a few of them as @rootwork explains very well-, being clearly marked as LTS -so contrib maintainers can know where to focus on too-, and the trade-off, for not raising the burden on the security team, could be other intermediate releases being supported shorter.

Yes, thanks for highlighting that @aleksip (I was the one who asked the question in the session too). It does make sense to me that contrib folks having to support (possibly multiple) old LTS releases would be untenable for them.

If shorter release cycles were adopted, 8 months would be better, but it seems like 12 months would be even nicer (not to mention easier to track in one's mind). So I guess that would mean supporting the last two minor releases -- not sure if that would be a dealbreaker.

To be fair, if the release cycle for two minor releases were 8 months, including RC candidates (when people should ideally be testing their sites!) the upgrade phase might be more like 9 months.

As someone who's contributed to lots of core feature issues, I totally get the motivation for having shorter cycles, because missing a release deadline is painful -- especially, as pointed out in the DrupalCon session, for companies/clients funding it. And as someone who works with a lot of small clients, having more frequent releases would be fine if the time were extended a little more, perhaps to a year.

Major issue summary rewrite with the work to date and current roadmap.

Fixing markup and whitespace errors.

+1 to everything that's in the issue summary!

For example, a contributed module author might choose to create a security release that is only compatible with the latest minor release of Drupal core

+1 for contrib authors having this choice. However, I think it's important for there to be a standard way for this choice to be communicated up-front to site owners, not discovered only after the security release is made. Site owners are currently informed on a contrib project's page whether the project has security support at all (e.g., projects with only alpha/beta/rc releases do not), and therefore are able to make an informed decision as to whether to install the module. Similarly, I think there should be a similar message as to whether the project is security-supported for just the current core minor or for both the current and previous. Perhaps this could be as simple as a checkbox on the project's edit page that the maintainer could opt into or out of?

Site owners are currently informed on a contrib project's page whether the project has security support at all (e.g., projects with only alpha/beta/rc releases do not),

Is this actually the case yet? I thought it was still being worked on: #2766491: Update status should indicate whether installed contributed projects receive security coverage

Right, that issue is still being worked on, but I mean the "This project is not covered by Drupal’s security advisory policy." message on e.g., https://www.drupal.org/project/admin_menu.

So, for example, adding another message there like This project's security support extends only to the most recent Drupal core minor or something like that for projects that don't want to offer support for the previous one.

Thanks for taking the time to write this up @xjm

Very detailed and thorough.

So maybe one of the things we should explore in Phase 6 (once modules have semver or at least enough support for core semver) is what impact core's security coverage has on contrib and if the info is surfaced anywhere? I think it would be best to gather feedback from contrib maintainers about that idea.

I think it would be best to gather feedback from contrib maintainers about that idea.

I’ll take that as an invitation …
I’m completely +1 for this, sounds like a great idea, and a very helpful change for site owners.

Regarding contrib modules, though, I’m wondering if it wouldn’t be better to require them (or at least very strongly recommend) to keep supporting minor Core versions as long as they are officially supported. Sure, it already sucks having to wait half a year until you’re able to use new APIs, and waiting for a year will suck a bit more – but the situation of having a sudden security release that requires you to upgrade Drupal to a new minor is a pretty chilling thought and should really be avoided, I’d say.
Apart from “Waaah, but I want to use that shiny new API now!” I can’t really see how this would make any problems or additional work for me as a contrib maintainer. I’ll just switch on testing for one more Core branch, that’s it. (Unless I’m missing something.)

+1 for this, for the reasons elaborated in #53.

Regarding contrib modules, though, I’m wondering if it wouldn’t be better to require them (or at least very strongly recommend) to keep supporting minor Core versions as long as they are officially supported. Sure, it already sucks having to wait half a year until you’re able to use new APIs, and waiting for a year will suck a bit more – but the situation of having a sudden security release that requires you to upgrade Drupal to a new minor is a pretty chilling thought and should really be avoided, I’d say.

I think at least being able to communicate this in a standardised way on project pages would be good, and that by itself is some kind of encouragement.

One issue which maybe came up earlier but not sure has been mentioned recently is deprecations.

i.e.
8.6.x has api method foo()

8.7.x adds api method bar() and deprecates foo().

Now if you keep using foo() you get a deprecation method on 8.7.x, but you can't use bar() and be compatible with 8.6.x because it doesn't exist yet. Semantic versioning could help with this, but we might also need to change our deprecation policy slightly. This is very different from contrib authors wanting to actively rely on new APIs.

Phase 4 is complete. At some point we will make a normal, non-security 8.5.x release containing at least this fix. We are still discussing whether to release it separately from Phase 5 or not.

Added #50 and #56 to the IS.

This policy
- was clearly stated here: https://dri.es/extended-security-coverage-for-drupal-8-minor-releases
- and clearly visible here: https://www.drupal.org/core/release-cycle-overview#current-development-c...

Phase 5 and 6 are follow-ups (with tickets included), the policy was accepted already.
closing

This issue needs to remain open for the completion of phases 5 and 6. Thanks!

Retitling as this is the overall plan issue for the initiative, not just a policy issue since last spring.

catch pointed out to me that this issue can be closed.

The current policy states

So long as the site is using a supported PHP version, security fixes are provided until the following minor release, approximately six additional months. (So, each minor receives security coverage for one year in total, and two minors receive security coverage at a time).

For me, that confirms the intent of the proposed resolution.

Thanks to everyone who worked on this!

Oops, yep, this has been adopted policy since 8.6 at least. Thanks @quietone and @catch!