[policy, no patch] Drupal 9 release timing and Drupal 7/8 EOL

Expanded EOL on first use for benefit of those not familiar with the jargon. Please expand the acronym LTS on first use for the benefit of those of us not familiar with the term.

Moving my comments from #2598662: Decide when Drupal 7 (and Drupal 8 and later) should enter the LTS and security-support-only phase (I keep confusing these two issues).

This will become even more the case for security support... It's hard to imagine being able to maintain security support for D7 for 4+ more years as in the current illustration, but the intent of that was so that risk-averse organizations could go from 7.x LTS to 9.x LTS.

I am not sure we will actually be able to offer security support for D7 until the creation of a 9.x LTS, so maybe we shouldn't imply that we will until we have some confidence and also actual experience with the 6.x extended LTS thing. It's what would be most advantageous to some audiences, but better to under-promise rather than over-promise.

xjm: why do you say "I am not sure we will actually be able to offer security support for D7 until the creation of a 9.x LTS?"

Is it a matter of much work there will be for the community or a concern with the infrastructure of D7 that causes you to say that?

I am not sure we will actually be able to offer security support for D7 until the creation of a 9.x LTS, so maybe we shouldn't imply that we will until we have some confidence and also actual experience with the 6.x extended LTS thing. It's what would be most advantageous to some audiences, but better to under-promise rather than over-promise.

Probably #2608062: [META] Requirements for tagging Drupal 9.0.0-alpha1 needs to be discussed a bit more before we can, but can we at least communicate some date and revise it upwards later? A piece of information many are interested in is, for how many years will D7 still be supported, and currently this is completely undetermined.

Per the discussions in this thread, at this point any D7 EOL dates based on a 9.x.0 LTS seem to be premature, so could we at least say something like, "9.0.0 + X years", along with "9.0.0 definitely won't be released before Y date", where any of "9.0.0", "X years", and "Y date" can be adjusted upwards later?

@stefan.r, good idea. And once 9.x.0 LTS details are more firm, those figures can be updated accordingly.

An important consideration should be that a move from D7 to D8 is likely to be quite involved. It might well be the last of the "rebuild upgrades" as we've become used to in the Drupal world, with much more smooth transitions going from e.g. the last 8.x to 9.0, but it shouldn't be ignored.

New sites are still built in D7 right now, so ideally we should ensure that such sites have a reasonable lifetime before we need to tell our clients, "Hey, we better build you a new site, because your current Drupal version is not going to be supported anymore". I'd say that means that D7 LTS needs to last for at least 4 more years. Preferably longer (4 years would actually be quite soon for us to have the aforementioned conversation with clients, and we would like some leeway to actually build the new site as well).

Another consideration should probably be, how much of an extra burden is supporting "9.x" in addition to supporting D8 LTS (This burden is likely to increase the more D9 moves away from 9.0 and therefore 8 LTS).

Just seen this thread. I'd agree with eelkeblok. Requesting a client invest a lot more budget in effectively rebuilding their site < 4 years after it being created, could lead to some resentment and not great for Drupal agencies or their clients.

I'd say having a reasonably robust upgrade path from D7 to D8 (minimum) and D9, should be a criteria for D7 EOL.

I am currently upgrading from 6 to 7. If I wanted to upgrade to 8 I couldn't as many modules are not available yet or stable in version 8. And now there is talk of version 9 and even 10?

I understand the idea of keeping Drupal current, but why start a new project when the older one isn't even finished?

Perhaps it is time to stop coming out with a new major rebuild every 2 years and start getting the current build fully functional and usable. Once done, then upgrade continuously as the trend is now with such projects as firefox, chrome, etc.

@sunward: that's what's happening now in Drupal 8 with the minor versions being released every 6 months: https://www.drupal.org/core/release-cycle-overview
However, releasing a new major version HAS to be done at some point, to remove deprecated parts of the code. This issue is to discuss when and how that should occur.

Strictly speaking, that point is being discussed in the other issue: #2608062: [META] Requirements for tagging Drupal 9.0.0-alpha1. However, up till now, releasing a new major version has been pretty closely tied to dropping support of previous major versions. But I think making that tie less strict, or removing it altogether, is at least open to discussion here. If 9.0 would be released within some timeframe after releasing 8.0 that we consider unreasonable to stop support for 7 (I've mentioned 4 years above), we should seriously consider removing that strict tie. Having said that, I would expect that to be a non-issue as 9.0 is unlikely to drop that soon. Or is it?

What makes this hard is that the new release cycle has upended things and we as a community don't really know what to expect either. This also makes D7 somewhat of a special case, since it is the last of the major releases of doing it the old way.

I'm sure that releases should be aligned with PHP releases & phpunit as well

1. I think we should aim to release Drupal 9.0 as soon as is feasible after resolving the items in #2608062: [META] Requirements for tagging Drupal 9.0.0-alpha1. That probably means 2019 at the earliest, but if we can do it early in 2019 on Symfony 4, then I think that's preferable to holding it up for Symfony 5.
2. I think it's okay for us to update from Symfony 4 to Symfony 5 in Drupal 9.1 or 9.2. I don't think we should do it in later minors than that, but I think it's okay to do early in the 9.x lifetime, especially if we let people know ahead of time that that's our plan.
3. Following Drupal 9 (meaning starting with Drupal 10), I really like the idea of scheduled major releases: either early or late in the year that follows the Symfony release. For example, Drupal 10.0 in early 2022 or late 2022, Drupal 11.0 in early 2024 or late 2024, and so on, meaning a new major Drupal version every two years, just like Symfony. Whether to do early or late in the year depends on how much time we think we'll need to incorporate the Symfony release that happens in November of the prior year. If we can get confidence that we can do that incorporation quickly, then releasing Drupal major versions early in the even-numbered years would be great.
4. I think it makes sense to keep Drupal 8 on Symfony 3, since we wouldn't be able to update it to Symfony 4 until 8.7 or so at the earliest anyway (due to the PHP 7.1 requirement), and I think that's way too late in the major version's timeline to make such a breaking change.
5. This all means that if we want to EOL Drupal 8 by November 2021 (Symfony 3's EOL) but not release Drupal 10 until sometime in 2022 (in order to have time to incorporate Symfony 6 into it), then we'll need to change our EOL policy (per this issue) and announce that. I think that's fine to do with reasonable notice, but that's all the more reason to get Drupal 9 out earlier in 2019 than later, to maximize the time that people have to upgrade from 8 to 9.

I think sites should have 18-24 months between a stable upgrade path from Drupal 7-8 (either 8.5.0 or 8.6.0) and Drupal 7 EOL

I agree with this. So, if we end up releasing Drupal 9.0 only 12 months after the 7-8 upgrade path is stable, I'd be +1 for extending D7's EOL an extra 6-12 months beyond 9.0's release.

True, but, if we keep 8.x on Symfony 3 and release 9.0 on Symfony 4, then contrib modules that work on 8.LAST and don't trigger any Symfony 3 deprecations will (mostly) work on 9.0, and could then have time to resolve the Symfony 4 deprecations before needing to get to Symfony 5. However, if we release 9.0 on Symfony 5, then that will be a hard break. Could we maybe get around that by releasing 9.0 on Symfony 4.4 (which would in theory have all the deprecations already finalized) and then release 9.1 on either 5.0 or 5.1? I'm not thrilled about that pushing 9.0 out to late 2019 or early 2020, but maybe that's the safest option?

I guess one possibility is if we get #2874198: Create and run dependency regression tests for core resolved before 9.0 is released, then maybe we can make it so that Drupal 8.9 (presuming here for now that that's the timeframe of 9.0 (early 2020)) can work with either Symfony 3.4 or Symfony 4.4 (composer.json allows either, composer.lock pins to 3.4). That would allow 9.0 to be released with Symfony 5, and D8 modules could run tests to ensure they're compatible with 4.4 and don't invoke any 4.4 deprecations prior to upgrading to Drupal 9.

If it's impossible to make Drupal 8.9 work simultaneously for both Symfony 3.4 and Symfony 4.4, that might be a reason to put Drupal 9.0 on Symfony 4.4 and Drupal 9.1 on Symfony 5.

Either way though, early 2020 could work well for a 9.0 release, assuming we're ready with everything else that's needed by then. And then maybe we can just stay on the early even-numbered year schedule for 10.0, 11.0, etc.?

Only downside with a 9.0 in early 2020 (rather than some time in 2019) is it only gives 18 months or so for D8 sites to upgrade prior to Symfony 3's EOL. But, if that's not sufficient, I wonder if we should extend D8's EOL 6-12 months beyond that, but that we update the composer.lock from Symfony 3 to Symfony 4 just prior to Symfony 3's EOL?

Given the pile of work at #2608062: [META] Requirements for tagging Drupal 9.0.0-alpha1, we might want to put a public stake in the ground of "not before 2020 at the earliest."

Given:

• The continuous upgrade path and D7 being "the last painful upgrade"
• Migrate
• The difficulty of balancing BC with security coverage for our dependencies

What I'm leaning toward is that we should EOL both D7 and D8 at the same time, one year after the release of Drupal 9 (similar to what PHP has scheduled with PHP 5.6 and 7.0).

The idea of long LTS releases that extend across two major versions was great, but based largely upon an expectation of our dependencies also having long support cycles and on Drupal updates being awful. With our dependencies now having 3-year cycles, we can no longer commit to supporting Drupal versions for 5-10 years. If we get the continuous upgrade path right (including making it better for contrib), it should only be about as disruptive as the current minor version updates. (And if we can get to the point where we do major version dependency updates in majors only, then that's one less thing to make people's lives hard in minor releases themselves.)

What I'm leaning toward is that we should EOL both D7 and D8 at the same time, one year after the release of Drupal 9 (similar to what PHP has scheduled with PHP 5.6 and 7.0). ... [...] ... With our dependencies now having 3-year cycles, we can no longer commit to supporting Drupal versions for 5-10 years. If we get the continuous upgrade path right (including making it better for contrib), it should only be about as disruptive as the current minor version updates.

Thanks for the time and efforts for this deliberated thoughts and reported considerations, @catch, @xjm, @webchick, and others. For me this reads very good and is understandable and very comprehensible. Some thoughts which came in mind while reading (maybe off-key or improper in some ways or maybe not)...

IF(!) upgrading from Drupal 8 to > Drupal 9 to > ... etc will be about as disruptive as the current minor version updates, or at least "close" to it, then all should agree with the consideration to shorten the update and security support cycles from 8 up. I do. But some may think of the issues they lately had with contrib module upgrades from 8.4 to 8.5 when reading this. And to bury D7 as soon as possible as the last "other" Drupal version before Drupal based on Symfony came around is more than reasonable for me but hangs on the same limb like the "Can I already use Drupal 8 for my Drupal 7 project" question, which is still around.

Let me wave for some known worries:

1. Still, upgrading to Drupal 8 or 9 from 7 isn't low-threshold and possibly the biggest upgrade jump an experienced Drupal user or contrib maintainer has ever done since then before. Without knowing numbers I would assume there is still a large amount of contrib module maintainers suffering with their upgrades a lot. If I would know how, I would help and support promotion for getting them all coming over to 8 and 9 ASAP since the new Drupal is the most tasty thing since fresh German bred if you ask me. But there are still some big players not greatly ported yet causing worries around, whom I carefully listen to. Especially when this modules are mandatory for widely used use cases of Drupal projects. Example: Date (all-day feature, date range issues, issues with referenced Date values in Calendar/Views integration, etc.) Event driven sites can not work with it as is in the moment. We still need more campaigns to get things done here, IMHO.
2. We should talk more about the plans of shorter cycles and the very deliberated reasons for it with the contrib world also on other places (not only on D.O.) to not cause even more solicitudes and scruples to start a project in contrib since we sadly have some bad examples in the last time of how disruptive minor updates can get between 8.4 and 8.5. We should communicate more (I do my best) that it has to do with the new platform and that it will not repeatedly happen in the next cycles again.
3. The plan mentioned by @catch to make sure that versions like Drupal 8 are more close and upwards compatible to the next like Drupal 9 is great but in the first cycle this can only be granted, if Drupal 8 gets as stable and feature rich as possible. At the moment it slightly feels like some Drupal 7 features aren't still available in Drupal 8 (some users do not seperate Core and main contrib features here, like many didn't when Views was contrib before). Therefore a more "stretchable" end of "get things in" time-limit is required for Drupal 8 to get a common ground between 8 and 9 as much as possible. Otherwise modules need workarounds for Drupal 8 again and contrib module maintainers have 2 very different versions again between Drupal 8 and 9, which would feel like it was before.

I strongly believe in that Drupal has made a sublime, incomparable great and almost impossible jump from an already great CMS Framework to an even more and very powerful and flexible web application builder and has a big future in the changing web. But like every jump, the landing can be a little bit wobbly and I feel the need to fix the ground and support the contrib area as much as possible to follow it. While I agree with most thoughts in this thread, do you agree with me, that considerations to shorten security update cycles is a very sensitive topic in this manner at the moment before Drupal 8 contrib area feels well-received?

To decrease apprehensions by users thinking of how hard it feels to learn Drupal 8 and how hard it could be to maybe learn Drupal 9, which definitely rises the inhibition threshold to decide to go on with Drupal by learning Drupal 8, users and developers who know better need to communicate and understand better that Drupal versioning is different here. We had Drupal 5,6,7 and have 8,9,10 etc. ok, yes, but actually we had Drupal 5,6,7 and now we have rather Drupal Symfony 1 (8) and Drupal Symfony 2 (9) etc. This would make more clear how close Drupal 8 and 9 is, why Drupal 8 has reasonable glitches (version 1) and that the learning curve of 7 to 8 is very unique.

This is my idea:

Drupal 9: long time support
Drupal 8: support 1 year after Drupal 9 release.
Drupal 7: long time support.

We need do better work in Drupal 9. Make Drupal 9 as success as Drupal 7.

Drupal 7 is the most success version in Drupal history.
Drupal 8 is a not success version in Drupal history. for exaple update Drupal 8 from minor version is much difficult:

update Drupal 8.2 to 8.3 is more difficult than update Drupal 6 to Drupal 7.
update Drupal 8.3 to 8.5 is more difficult than update Drupal 6 to Drupal 7.

This is my real experience of Drupal 8.

We need prevent this case in Drupal 9.

this is my proposal for release Drupal 9:
https://www.drupal.org/project/ideas/issues/2961289

@catch: wow! awesome write up! I will read this carefully twice. Thanks for the hard work on this. 1+

@g089... please beware that D8 sub version release cycles have a lot to do with the immense and hard work done on new framework implementation and adaption of all the new APIs for D8. D8 is a completely new beast. From my impression it never has been so much added to Drupal core than in the "from D7 to D8" development time. The feature richness of D8 core is mind blowing large. With many big adaption from the contrib area. (I bow my thanks to all the hard workers on this) - So, in my inherit opinion, the release cycles of D8 sub versions was a required "buffer" to get it all in before feature freezes and, while I possibly missed some important reads, I think the whole release cycle policy has changed for the future anyway (to the better I think). You cannot compare it directly with the core version release cycles of before (not sure). But maybe somebody else can explain it better than me in the moment.

You're pretty much right on the money [except for the reasoning behind feature releases, as @wim leers points out]. I think the ideas around feature releases within the D8 lifetime and when to move to D9 have evolved the past few years a bit like this:

1. "Yay feature releases! D9? Something about backwards compatibility breaks... Dunno...D8! Yay!" (has probably been marked with some blogpost, but I can't really recall).
2. "Transition from D8 to D9 should be controlled. New features can just be added to D8, in minor releases. New functioanlity and APIs that replace old stuff should have the old stuff deprecated, not removed. D9 can be released when there is enough old stuff accumulated, we'll rip it all out. If everybody follows all the new stuff, transitioning from D8 to D9 will be pain free." (Big if in there, obviously ;)). This was marked by a blog post from Dries.
3. "Like before, but we also need to take into account the very many dependencies in Drupal now. They are likely to force us to do D9, if we want to keep it sane." This is marked by catch's blogpost above.

So, in my inherit opinion, the release cycles of D8 sub versions was a required "buffer" to get it all in before feature freezes

I think you're referring to minor versions and the fact that they can contain new features.

You say you think that D8 has minor versions just to ship all the features we wanted to have in D8 from day one. I can say this is absolutely not the reason. :) While Drupal 8 was being developed, we weren't at all planning to include Workflows. We weren't planning at all to have BigPipe. We weren't planning at all to do the Umami install profile. All of those were proposed after D8 shipped. And the minor versions allow us to ship new features now rather than years from now: it allows us to add new features to Drupal 8 (without breaking things), and not have to wait for Drupal 9. Precisely because it no longer takes years for new features to actually be usable, we're seeing more initiatives than ever before!

And the minor versions allow us to ship new features now rather than years from now: it allows us to add new features to Drupal 8 (without breaking things), and not have to wait for Drupal 9.

@Wim Leers: That's what I wanted to embrace with my saying. Maybe you've been misleaded by my phrasing, sorry for this if that's the case, but it is exactly what my comment was all about.

You say you think that D8 has minor versions just to ship all the features we wanted to have in D8 from day one.

Nope. That's not what I wanted to say. Since I assume that new feaures can have the need of another feature, and longer planned features can create ideas popping up in the middle to combine with another feature or new requirements or even (as often happend) completely different roads have to be gone too, I simply assume that there is no strong line between a planned or not planned feature strictly from day one, two, three or four. Even some long term requests from times in the middle of D7 require to have other features in D8 before even being able working on them. All I tried to do is, to help somebody calming down on the furstration with new versioning and that I think they can't compare Drupal 8, 9, x etc update cycles with anything before no more. Which was my main statement. Especially since there are other dependencies now coming into count like catch stated already with the Symfony example.

we're seeing more initiatives than ever before!

Exactly. That's what I was after.

Let me come back to the actually comment I wanted to add today since I met more complains again regarding the update cycles:

As I tried to explain already some comments above (my first chiming in here I think): it is very important to pick the users and part-time contributors up from where they come from and help them to better understand the changes and why things seem to be "more complicated" from their point of view. It does not help them to explain it from ours. While some things actually aren't more complicated, or at least are planned to be even less complicated on the end, for them they are not. A lot of times I get calls like: Drupal update > Drupal broken. Literally every week 2 times! Issues like this (read the first comment) and this are just a few of many examples showing off what I was actually warning about since 2 years from now regarding better communication. In a positive and constructive way. Smaller shops really struggle. And the sad story behind this is: how hard all have worked on it to make Drupal 8 the hottest thing since Entrecôte grilled on thyme-marjoram butter! And it defintely is!

That's what I was after and what I always try to weight in and what I try to make understand to those who are frustrated. xjm did a wonderful post about the topic "Don't forget that people have worked hard on what you complain about" (sth like that) which I can't agree more on. Wonderful write up. And this is where both ends hit here. One end is the frustrated user, on the other end is the one who has worked hard on it. And I say it again: The way out of it is not to complain back to the frustrated users, but is to better conduct those users into all the new terminalogies, new update cycles, new command line tools, etc. Or at least show them some windows to look through. Which leads to another example of these both ends: many has worked hard on the new doc system and it is great! Modern, lean, with the new discuss and edit functions etc. I love it! But this is only one end. On the other end there is the user who has tried any of the newly suggested installation methods documented and discussed there and all of them break on the next update badly without any idea what's going on. How to convince them of the new docs?

We need more of this awesome write ups like the ones of catch, xjm, Dries and others and we need to share them as much as possible around to make sure that they cross the users eye when googling for Drupal around. The docs are great but there are still not hard enough moderated and updated (which is almost impossible to achieve, I know). I also recommended already to add a bridge making it possible to link issue reports to docs, which will help people to find possible reasons why the documented method doesn't work 100% like documented. But ok, I peter out here (digress). This issue is about release cycle plans for Drupal 9 and parallel security updates for Drupal 8 and EOL of 7 and 8 etc. So let's get back to topic.

+ 1 for diqidoq
"
it is very important to pick the users and part-time contributors up from where they come from and help them to better understand the changes and why things seem to be "more complicated" from their point of view.
"

Complicated kills Drupal 8.

For Drupal 8, there are 214,873 sites.
8.5.3: 84,275
8.4.8: 8,908

2 months after the security update, there are still 121690 site in unsecurity state.
56% Drupal 8 sites is not security。

Updating in Drupal 8 is super painfull. it is much different from user expectation:
https://dri.es/making-drupal-upgrades-easy-forever

Updating is painfun but no one knows how to fix it:
https://www.drupal.org/project/drupal/issues/2865702

Common user's comment on Drupal 8's updating:
"
Still dealing with this, totally unable to update to ~8.5. Incredibly depressing. Drupal is garbage.
https://www.drupal.org/project/drupal/issues/2865702#comment-12593992
"

"
Same here, g.jordan. I have two sites I can't update at all. :(

https://www.drupal.org/project/drupal/issues/2865702#comment-12614081
"

@g089h515r806: I see your points, but please, you only extracted a part of my quote. I also stated that it maybe isn't that complicated like it feels for some users, or at least is planned to become even less complicated and is on the way but is missing some smart communication on it. I didn't say it IS complicated.

Your report is very appreciated but let us move it to an issue especially made for this topic. We move out of focus here. If there is no issue yet about it, let us create one. But let us turn it into something positive and constructive then (not only complaining about it), with thinking about solutions, which are possible to achieve. And let's get back to topic here: Drupal 9 release timing and Drupal 7/8 EOL (plan).

I suggest this roadmap:

Never release a new major before the migration of *all* core modules work 100% (zero bugs) and without any data loss for a minimum of 2 years. This is the typical time most people need to upgrade as all modules are missing at day of major release. If libraries security support ends earlier - it still need to be backported and supported. This ultimately makes clear where priorities need to be and why - hopefully.

If an upgrade like D6 to D8 does not work - why the heck has D8 released - the security updates are not allowed to stop. There must never be a deadline for this as people are stuck at D6 forever otherwise. Offering highly payed LTS security support from companies is no acceptable solution.

I have not a single site upgraded from D7 to D8 yet as everytime something is not working and crashing in migration.

Never release a new major before the migration of *all* core modules work 100% (zero bugs) and without any data loss

Good luck. I mean with any software which has ever been developed...

Offering highly payed LTS security support from companies is no acceptable solution.

I am still not getting how people assume that the world is for free ... But apart from that: From where do you take this insunation?

I have not a single site upgraded from D7 to D8 yet as everytime something is not working and crashing in migration

Well, TBH, this is rather showing off your capabilities, then the drawbacks of Drupal. Sorry. This is called "evolution". And it is up to you to fight for your part on it. If you just want to complain about the changes, ok. I am empathic enough to follow your issues. And this is the right of the free. But it is also very expounding and unbosoming.

It is not about everything is free. It is about releasing a product that has no upgrade path or only a broken one. Until D7 we always had a fully working upgrade path in 7.0 and with 8.5 (~3 years after RTM) this is still not the case. And here we talk about D9. Seriously? We should not allow moving forward if previous todos have not completed as for some things nobody has a solution. Not everyone stands on green field.

This is not about my capabilities at first sight. It is all about wrong or no priorities on upgrades.

Let me rephrase (Sorry, my English is obvisouly sometimes misleading): I just felt the need for defending against complains, which fit into the "Complains about something others worked hard on to make it better" category. I didn't wanted to make you feel bad or something, but it happens so often (by everyone, also by me) that people complain about evolutionary changes which are required to hold up with the overall evolution, so that all we can do is to try to make it better and try to hold up with it as much as possible. Drupal made a huge jump forward and this causes momentum we all need to handle, sure.

I think it is no exaggeration, when I say, almost everybody feels what you feel from time to time, even those who work hard on it daily. But they possibly know exactly for that reason better than you (and me), that this is possibly the best way from the temporary point of view.

And in the moment when you call it a "product" ... (You know I don't need to finish the sentence) ...

Although it might be redundand: I can't use Drupal 8 for one project because load of contrib modules are not available for Drupal 8. I fear the day of Drupal 9 release and the EOL of drupal 7.
For example Rules: In my opinion it should be in the core. But until today there is no stable version for Drupal 8 available. Because of Rules I even consider downgrade a new (nearly ready) Drupal 8 project to Drupal 7 right now. I can't find a way to do a special job without Rules. And the current Alpha doesn't work for me.
I could tell you 20 other modules, that are very important for me and are not available in Drupal 8

Please don't release Drupal 9 as long as so many modules aren't available for Drupal 8. Or keep Drupal 7 in support some more years. It would be a huge problem for every no-coder using Drupal 7. At least larger projects that are not doable with core alone.

Thanks for listening :-)

@catch

Thank you for your reply and the link. Quite interesting to read that stuff, especially the discusions about why the people don't update from 7 to 8 and that it might be because of the much work to do that. And plans about update paths and so on. I am not a programmer and I probably never will be. Sad but true.
But so I can tell you one thing again right from the sight of a non-coding sitebuilder: I'd love to update to drupal 8 and I would start today. No matter how much work the update would be for me. But I can't because I used countless contrib modules to bring certain functionality to the site. Most of theese modules got no upgrade to Drupal 8 (surely 20-30 modules I use) and there is no alternate module available. Although I like Drupal 8 very much I can't use it and it feels like an early beta version to me. Not the core. But the module universe. The unbelievable huge amount of functionality that is available for Drupal 7 is lost in Drupal 8. But for me exactly this is the power of Drupal! Drupal 7 of course. Even without coding expierience I am able to create a complex, dynamic, automated project that I never even dreamed of before until I came to know Drupal.

When releasing Drupal 9 means to stop patching Drupal 7, all this will die. What can I do when Drupal 7 stops and the needed modules aren't available in Drupal 8? It is nice to read, that Drupal 9 can use Drupal 8 modules. But is this a help for someone like me?

I appreciate this plan. Great idea and I hope you get it done. But please consider another idea: Slow down bulding Drupal 9 and help upgrading the Drupal 7 modules to a working Drupal 8 release. I am sure, that every upgraded module would motivate some users to upgrade to Drupal 8. I surely am not alone in this point.

Or let Drupal 7 alive and give at least security patches without the sword of Damocles (EOL) over our heads.

It feels a little bit like Microsoft has ended Windows XP without updating Outlook. "Hey guys, Windows 7 is a great System, use it! We know, the Outlook developers don't have time to update Outlook right now. But sorry, we have to stop XP. Sure you will find something else than outlook. Windows 10 will be even better! Still no Outlook, but you can use the alternate mail client you might have found." And then they start internal meetings to find out, why a lot of people didn't update to Windows 7, expecting that they will follow to Windows 10...
I know. Bad example. Why? In case of Outlook there ARE alternative products available...

Rules is definitely a big one; it's blocked on funding: http://d8rules.org/ Donating there will help expedite it.

If there are others holding you back from adopting D8, make sure they're tracked in https://www.drupal.org/project/issues/contrib_tracker. This is where people are helping each other out on e.g. how stable the modules are, possible alternatives, how to help unblock development, etc.

@Likos73

I think you make a good point.

A few things to add to the conversation:

1. when there is a great deal of disruption between versions, people tend to look for alternatives. Thus, we may lose sites to competing products. Will we gain more people because of D8's new features than we lose? "Eventually yes" is my guess but we shouldn't be surprised if we see a dip in overall installations (D7+D8) in a few years as D7 installations drop and are rebuilt in some other tool.
2. the jump from D7 to D8 was absolutely necessary, in my view, for the project to stay relevant. Taking the bitter medicine.
3. there may already be companies that will provide security patches for D7 for a fee. I seem to remember seeing one recently. This will, at least, extend the life of your current website by several more years while you plan next steps.

Rules is definitely a big one; it's blocked on funding: http://d8rules.org/ Donating there will help expedite it.

@webchick: Can we meet up on #slack or #irc regarding this (only 5 minutes)?

when there is a great deal of disruption between versions, people tend to look for alternatives. Thus, we may lose sites to competing products.

@aangel: As I have stated already above and elsewhere, this type of arguments (points) are running in cycles all over the places commonly if a "part of Drupal seems not to fit expectations" (it even was in D7 times and so it was for other "products") and they are all the same way "destructive" (no offense). It won't change anything but making the wrong waves. It also conveys the impression that a certain "crowd" (not you) wants to blackmail core contributors to leave the bandcamp for another tool if expectations get not fullfilled. And it conveys the wrong impression that these contributors only work for those to stay. But what they do not understand is: there is only one person which gets hurt by leaving. The user who leaves. And will never be able to see the power of Drupal 8. It is such a beast. We build a large complex web application with it at the moment for an online driven cooperation system without one single custom module (I sadly can't say more here about it) which is absolutely impressive and absolutley impossible to make with any other framework this way. It is important to undertand how web has changed and that the borderline between simple vcard showcase sites and applications gets bolder and Drupal decided to be in the application camp, not in the vcard one (while even being able to serve a vcard with 3 clicks). We need to encourage people to try using Drupal 8 for their plans to build dynamic web projects "with a mouse click" and need to create a certain exchange energy between all of us to speed up contribution and user reports. Therefore we need to make understand how hard it is to do exactly what Drupal is best for: mixed flexibility with ease of use. Of course it will have edges. Of course it feels not easy enough for some of the users. But we won't make this happen by only complaining about that some things in the corner may not work yet and that it would cause that people "change their tools". There is no further inspiration in this words. Nor is it true exactly. Because you can't change to something else with the same feature set because it simply does not exist in that way. In fact, there is no competitive "product" when you check the details.

@diqidoq No threat to the developers of core or contrib modules intended (myself newly being one of the latter group). Plus, I am doubling down on my commitment to Drupal so I largely agree with your assessment about competing tools in the open source space.

However, it is a widely understood truism that difficult upgrades give people a reason to look elsewhere. That's one reason why software companies go out of their way to make upgrades easy. It doesn't guarantee that a customer stays as a customer—but it's usually a prerequisite.

Further, I love Drupal but it's also widely understood in our community that the technology was getting long in the tooth, which is why I wholeheartedly agreed with the move to Symfony, composer, etc. We are making all the right moves, in my view, even if the medicine is sometimes bitter.

And the move isn't complete yet: the entire system isn't object oriented yet and likely won't be for at least another two major versions (i.e. Drupal 10).

Or let Drupal 7 alive and give at least security patches without the sword of Damocles (EOL) over our heads.

That's exactly what @catch is proposing in https://www.thirdandgrove.com/long-road-drupal-9, which suggests releasing Drupal 9 in 2020, but keeping Drupal 7 security supported for either 1 or 2 years after that (2021 or 2022). That still needs community discussion, and approval by the security team, but that's the current proposal on the table. Tagging this for an issue summary update, since the current issue summary doesn't reflect what's in that blog post.

Whether 3-4 years from today is enough time for "enough" of the current Drupal 7 contrib modules to have ports or viable alternatives within Drupal 8 contrib is hard to predict.

@effulgentsia: 1+!

Exactly. Thank you!

+1 to the plan to release Drupal 9 in 2019.

I am also waiting to upgrade from Drupal 7, and the plan to continue its support separate to the release from Drupal 9 is a good one.

IMO one of the reasons why upgrades have been so hard recently have been the huge amounts of new features and development for each major release.

Moving on to regular major releases on a timed basis (some of it due to symphony support cycles) is IMO a very good thing especially as it should allow continuous updating to new versions.

I agree that it might be useful to continue to support Drupal 7 without regards of Drupal 9 releases, because it simply is the most used and the most successful version of Drupal so far.

Roughly 80% of the tracked drupal sites still use Drupal 7 and an EOL before 2022 would deal major damage to the Drupal community and might cause a significant number of sites to use other CMS instead of Drupal.

Nonetheless, some official decisions on how long Drupal 7 will be supported should be announced probably sooner then later, since it affects projects that do not want to run on Drupal 8 to hesitate using Drupal 7.

Expanded LTS to long-term support on first use for benefit of those not familiar with the term.

For those who may not have seen it, Dries has posted a blog on this subject here: https://dri.es/drupal-7-8-and-9

My understanding is the announcement covers all questions raised here so closing this. See all the details at https://dri.es/drupal-7-8-and-9 Thanks all for your input!

Yes, but we need to document it somewhere on d.o e.g. https://www.drupal.org/core/release-cycle-overview

You are of course right. Updated https://www.drupal.org/node/2383987/revisions/view/11133105/11151440.

When is the Drupal9 branch opened (and actively maintained)?

the answer to my question will be in #2608062: [META] Requirements for tagging Drupal 9.0.0-alpha1