 So this is checking on Drupal 8's rapid innovation promises and it's maybe both an educational session for those who may not be involved in Drupal core development and maybe hopefully a good discussion for those who are. So the question, the first question is who's, who considered themselves not involved in core development? Great, great. So let's start with a quiz. How many months, months elapsed from the previous version for the following Drupal core versions? Any guesses for Drupal 5? And the other guess? Two? No? Eight is good. You win. So I don't have prices, sorry. Drupal 6? Any guesses for Drupal 6? How long it took between Drupal 5 release and Drupal 6 release? Thirteen? Any guesses for Drupal 7? Months? That's a bit too much. Thirty? Thirty? Twenty-five? Well you can see the pattern. This is real data. So how many months did Drupal 8 take to deliver from the Drupal 7 release? It's forty-nine. So it's not a good trend. So if you draw the trend, we are like skyrocketing to the Mars and we don't need Elon Musk to solve it for us. So we've been slower and slower releasing the new versions and it's been getting ridiculous. I mean, no, that's not good. So the question is why is it wrong to take our time? Because some things require a lot of time to work on, so why is it even wrong to do that? So the problem is that a lot of time allows us to do a lot of change. So we can do a whole lot of changes that then makes it very hard to adapt to. And what's even worse is all of those changes result in even more changes because we now started rewriting this API and then we need to adapt everything else that's been going on to that new API and we just built this feature but then we have this new API and now we need to rewrite that feature for the new API that we just built a year ago. So we did a lot of duplicate work because we just worked on a feature and then later on we needed to adapt to the new API and we write the whole thing all over again. So that resulted in even more change, so it's just like added on and it just became a snowball effect and towards the end of Drupal 8 we were just like, just release this, whatever, because we can do this however long we want. If we don't set a limit for ourselves then we can go on with this for however long. And then this becomes very costly to upgrade. We change all the data models, we change all the APIs, so people who need to upgrade to these new versions they need to rewrite their code as well. There's the version pressure that if you want to get a change in Drupal Core you know that you need to get it in this version because it will only get released four years later if you don't get in this version. So everybody tries to push in their stuff, they are very anxious to get their change into Core in this version because otherwise it's going to be four years and that again results in even more change and even more change that others need to adapt to. And the worst thing for all of these changes is that we are doing this in our own bubble because it's our development version that nobody uses, it's our own playground that we are working on for four years and nobody is using it. So we are making assumptions and we are working towards a dream client that hopefully wants these features and by the time it's released in four years it may or may not be relevant anymore, it may or may not be applicable to the date that the four years later when it actually gets out. So maybe we developed a brand new exciting API at the first year and then three years the web moved on and now there's an entirely new approach to something and we are still working with the old system. And then all of this work and redoing the work and doing it in our own corner results in burnout with developers because they don't know if their change ends up in this version, they work very hard to get it in with this version pressure. They don't get any feedback on whether it's good or not, only four years later. Sometimes their change just gets rejected later on when they already worked it out and it looks good now and then they say oh no, now we are in API free so you're not allowed anymore. So it's very hard to convince people to take on this kind of pressure and to work on the system and it only then down to the very dedicated core contributors who can sustain this kind of thing. So it's very low incentive for core contributors to get involved in this cycle tucked away in a corner. So that's a lot of problems that we've had and that resulted in this graph because we always wanted to build in these nice new things and then that just resulted in more change and then we've had this pressure that is never going to be released if we don't get it in this version. So we just added up because we were also trying to be nice people to our contributors because we love our contributors so we don't like to say no. So we were saying yes to a lot of things and yes to even more and more things and that just resulted in a snowballing effect of change. So what we had in mind to solve this is to try to turn back this tide and just say that now we want to get back to even pre-Drupal 5 levels and release stuff much sooner and much more often. I just named these Drupal X, Y and Z for theoretical reasons so we can talk about the exact details. So basically the idea was to break this down to release as much more often so we can relieve the version pressure. We can get stuff out to actual people and get feedback about them and that we can actually follow the market. We can work on things that the market actually values at the time instead of things that they value now but will not value for years later. So to do this we decided to set schedules ahead of time. We say we need to release this at that date and then adhere to that. So what we decided is to do roughly, release is roughly every six months. We already released Drupal 8.1 and we are in the process of releasing 8.2 next week. Everything is in row to release that so I don't think we have any blockers to do that next week. And that helps us to set a deadline for everything to work on. So the model looks like this, so every six months we are coming out with a new release and then we can work on delivering features in that release. So that means that we get out our stuff much more often, way more often than we did before. We hopefully clear the version pressure so that people who don't get their feature in this version can very soon get a new version where their feature may be released and then we get the market feedback sooner. We also wanted to keep quality assurance in this. So each of these releases gets their own quality assurance time. So we have a beta period and an RC period at the end of these releases. So in fact the effective development period is more like four months and then we go into beta and then we go into RC for ensuring quality of that release. So that's a very short time compared to four years, 49 months, four months against 49 months is kind of a difference. And then we wanted to attack this problem that if we have all of these releases then we will have a support nightmare of supporting a lot of things, a lot of branches going forward. So what we decided is we also want to get people always on the latest releases and we kind of force them into that because what we do now is when we get out with a new release we stop security support for the previous one. So this stops here and then we start supporting this one and this stops here and then we start supporting the next one when it's released. So if you're running Drupal 8.0 something right now on some site then you may have security issues that are not fixed because we only support security fixes on 8.1 currently and once 8.2 is released we drop 8.1 then 8.2 is going to be the one that has security support. So this means that we want people to always use the latest versions so they would update within these small chunks and they would always get all the stuff in their hands that we wanted to deliver to them and we get more feedback on all of these things. And that with the current version yes the current stable version gets the security support and that also reduces the support burden on us so we don't need to support multiple branches that may have different code and some different APIs. But this would still be pretty bad if we would be making all kinds of arbitrary changes right? So if we would remove the form API in this version and then we release a new one then all the contributing modules that use forms would be up in the air and he wouldn't be able to use it. So this in itself doesn't solve the problem that people are able to upgrade soon enough. So what we decided to adopt additionally to short releases that are scheduled is semantic versioning. And semantic versioning is basically a major or minor patch version number which allows us more granularity in expressing what we change compared to what we had before two numbers in Drupal 7, 7.1, 7.2, 7.3. And so what we can do here is if we just fix a bug then we can increment the patch version number. If we want to do backwards compatibility affecting changes that are not backwards compatible anymore then we increase the first version number so that would be Drupal 9. And if we want to add features without backwards compatibility changes we would increase the minor version number. So the exciting new thing that we got now is we can release new things with new exciting additions as long as we don't break backwards compatibility we can include new APIs, we can include changes to APIs in a backwards compatible way, we can include new features in a backwards compatible way in minor releases. So this allows us to drop support every six months for the previous release because it's very easy for you to upgrade to the new release because it will still work with all the modules that you have and all the APIs you have. And it also allows us to put in all of these new nice shiny things. So the version numbers for x, y, z and up 8.0, 8.1, 8.2, 8.3, etc. So these are the ones that we release every six months. And then we can put in new features and new APIs and change APIs in a backwards compatible way. And so we've been quite successful in that I think because we got several new stable features in 8.1 like the admin help page is now more flexible so modules and themes can add new help sections and it lists all the tours that are there. It still did not make tours any more popular or successful but we tried. We've added language button to secure editor and spell checking. The installation profiles can preselect languages in 8.1 and views provides rendered entity field handlers so that you can render entity fields in views. So we've delivered several exciting new features I think and we've also delivered several new exciting APIs, maybe even more than features. Entity types can specify translatable plural labels so they can say articles and article as a separate text. We have a revision log interface in 8.1. We have content entity base for key fields defined by default. We have automated testing support for JavaScript. So we can add all of these new things and things like automated testing for JavaScript is something that we probably should have done for some time. We are catching up with modern age of development but we now can do this and we now can release this in major versions and it's as a new stable API that people can use. And these do not disrupt anything that's already there in core for them to be included. And then next week, these things will be stable features. So we now have relative URLs automatically converted to absolute ones in RSS feeds. We have revisions by default on new node types. We have a redirect option that you can configure in site-wide contact forms. You can redirect people to other forms. We have feedback for administrators when you create something new on the site, then you get a link to that. We made it possible to select the view mode in the formatter form so you can configure how comments are displayed. So that's coming out next week, all new stable features. And we made a lot of new APIs available. So we added support for reading configuration and these as REST resources. We've added dedicated resources for user login registration and logouts. You can now choose the authentication mechanism in REST export views displays. There's simplified REST configuration and we've added support for specifying the field item delta in entity query conditions. So there's a lot of new API possibilities in 8.2. So we are going forward and we can make all of these changes now in the new system. And what's even better is we're working on Drupal 8.3. So even though we haven't even released 8.2 yet, what happens is each time we are going into a beta phase for a previous release, we open the development of the next version. So all the things that did not manage to get to the previous version are now possible to get to the next one. So 8.3 that's gonna be released next April something already has a simplified and unified views listing interface that's similar to what other listing interfaces are for administration pages. It's easier to find what views you have and scan them and search in them and it's easier to use. So this also allowed us to say that development is always open for our core. So when something goes into beta then the next version, development version already opens and allows us to put in even more things. And then the question is, did we succeed in adding new stable modules in core? No. No, we did not add any new stable modules in core. Why? We did not have enough time, I think, to do that yet. So Drupal 8 was released a year ago and we did not have anything that met the criteria quite yet. We want to implement the right things based on feedback. So we are working on things that we want to make right. Drupal core just has a huge list of requirements for a module. It needs to be performant, it needs to not break anything else, it needs to provide a stable API that you're not gonna change, it needs to have a sort of stable user interface that you're not gonna drastically upset and all kinds of other things. And as I said, we don't want to work in our own bubble on our own things, we want to get feedback. So we did not want to go right into adding modules without having that kind of feedback. So the question is, how can we work on new things for core and get that feedback? So one of the options is to start a contributed module or a sandbox and then work on something there. But that does not have enough visibility, so you would not get to try out those modules with downloading Drupal core, you would need to know that the module is there and you would need to manually download the module and try it out. So what we decided to do instead is to introduce a way to sneak in modules in core that are not yet stable. So we introduced the concept of experimental modules. Who's aware of what an experimental module is? So half of the audience, that's good, so that makes sense that I have this section on what is an experimental module. So experimental modules basically are not yet stable. They don't need to meet all the requirements of a Drupal core stable module that is supported. And they have their own cycles of stability. So they start in Drupal core as alpha modules that are much like when a Drupal core version is alpha. So it may have all kinds of bugs and it may have unstable APIs that we are still working out. It may have a prototype of a user interface that we still want to work out how it's going to work. And then it goes through to beta and RC and stable. And so these have their own statuses, but we put them right in core. Because putting them right in core allows us to put it in your faces. And so for you to provide us feedback on whether they work or not. And this allows us to experiment with things and get feedback much sooner than trying to work on the module in our own bubble and work for an imaginary client and figure out what the imaginary client may want. And then put in something stable and then figure out that's not what the imaginary client wanted. And needing to fix all that stuff with a stable module. So this allows us to move much more freely and change a lot more things before we agree that it's good and it implements something that's valuable for people to use. What it should not have is it should not have known security issues and it should not have known data integrity issues. So if you download an alpha module from Drupal.org randomly a contributed module, it may or may not have security issues. It may or may it may it will not get security support from the security team because it does not have a stable release. In core, however, we cannot really have that luxury to put in something that we know has has a security problem. So we do review these modules for possible security problems so that they are going to break your site. And there's also a requirement that they are ideally be uninstallable if at all possible. Maybe you're losing some metadata, but you should not lose the most important data on your site. So the policy says that they should be removable without lasting disruption. It's the codified way of saying that. But the most important thing, though, about these modules is that they have a plan of path to stability with a timeline. So the idea is we put them in core and we want to ideally have them stable. We don't want to keep them there alpha. So we want to have a plan of how we want to complete this. So when we put these in core, we have a plan of what it needs to happen for it to be stable and for those issues to be open. And so we can work on those things to get them stable. And that obviously could change on feedback. So the reason we put it in core is because we want to hear that feedback on whether it works for you, whether it solves your problem, whether it needs to have a different user interface. There's a typical timeline of two major releases. So we also don't want to put stuff in core and then leave it as alpha, beta, something that will never mature into stable state. So it has a timeline of possible removal if it's never stable. So the process looks probably more like this. So if it does not work out, there's maybe no movement on that going forward from alpha or beta, or it turns out to be not suitable to solve the problem or the problem that we wanted to solve turned out to be not worthy to solve in core or it was a duplicate of some solution that we thought is better than we can remove the experimental modules. So they may or may not stay forever in core. It's also good to know. They also should not be used on production sites, ideally. So they are very easy to enable. But we have them as a separate section and we have a warning when you enable them is these are experimental modules. You may not want to use them on production sites. But the only way we get feedback is if you use it at least in your development environments and tell us if it works for you if it solves your problem or not. So as a status check on our experimental modules, we have a lot of experimental modules in core now. We have inline form errors, which was edited in 8.0.0 and is alpha. So now that we're gonna release 8.2 and our two major releases passed. So now inline form errors will be in danger of being removed in 8.3 if we don't succeed moving it forward. We have the migrate module that we added in 8.1 and is still alpha, but it's close to having a beta. Close to moving to beta. We've added big pipe in 8.1, which is now in beta in 8.2. So it matured into beta. That's an example of a module that had some problems and resolved their problems and moved forward. We have the place block and the settings tray modules, brand new in 8.2 that are alpha. They have a lot of user interaction issues that they wanna work out to make them better work together better. We have daytime range module, which is alpha. It has also some user interface issues and some other problems. And we have content moderation also in 8.2. So there's a whole lot of things that we put in and all of these will be in Drupal 8 releases by next Wednesday and none of them are stable. So we are looking for feedback on these and we want to improve these things. And then finally the question is how does someone get in this process? So okay, we now have a way to release often. We now have a way to do these releases in a backwards compatible way. We also force people to upgrade to these or we stop supporting their site. And we also have a way to put in things that are not fully baked yet. So we not just release often, we can also release things often that are not yet done and put it in people's faces and get the kind of feedback that we need to make it work for you. So the final thing that we just started, we just launched a week or two ago, it's very new, is the ideas process. Who heard about the ideas process? Okay, even less, it's like five people in the room. So let's talk about that. So the ideas process basically tries to solve the problem that you have an idea for core and the traditional solution to that is you write a patch but then you post it on the issue queue and then you perfect the patch and people come in and they tear the patch apart and you have this white space problem and your columns are not in the right place and the interface names are not good and your JavaScript coding styles are not nice and anyway, you should put this file there and that file there and it should be a plugin and whatever and then you work on it for five months and then a core committer comes in and he says, we don't need this for core. And then you're banging your head on your desk because you worked five months and you solved every problem but all the problems that came in were stylistic or where they were like about the patch that you were working on, they were not really about the idea that you want to get in core. So what we want to have instead is first, define the idea, what do you wanna do? Very high level, maybe one sentence, maybe I want a new theme in core because of this and this. So you define your idea that you want feedback on and you can put this somewhere and then you get feedback on your idea and you don't start working on a prototype or you're not plan out how it's gonna work, you don't write any code, you're not gonna have any white space problems because you only have this idea and you wait for feedback on how's that gonna work. So this point, your feedback is, is it core worthy or not? And whether it affects subsystems in core or not. And if people tell you it's worthy or not, we'll talk about who's those people are gonna tell you, then you can work on a prototype and see if you can actually solve this problem in a rough way and this can be paper prototypes or this can be very simple solutions that you can see if it solves the problem or not and that helps you plan out what actually needs to be done in core, okay? And that may inform if you're working on the right idea or not. So this is a very high level process to even figure out what you wanna work on and to generate a plan and figure out if your idea can even be done in a feasible way. And you may not need to write even a line of code to do this, you can do paper prototypes or you can do clicky prototypes that are nice and user testable. But basically the idea is to figure out the plan and the feasibility of this idea starting with if this idea is even worth for inclusion in core. So the system that we set up to use for this is its own project on www.truple.org www.truple.org slash project slash ideas. And we just decided an hour ago that there are gonna be meetings with core committers and they're gonna look at this queue and they're gonna tell you if your idea makes sense for core or not and they're gonna tell you encouraging words about your ideas or maybe discouraging words about your ideas. So you can tell upfront not to spend five months on this thing because it has no chance to get in core or you can tell upfront that you can move forward to prototype this idea because it's a good idea for core and then you can plan out what needs to be done and you still didn't spend five months on it you just spend like a few days or a week to figure out the feasibility in the plan and then talk about it again. So the ideas queue is preceded now with a few pre-existing ideas that are ideal candidates for this. So like create a design for a media library or a contact module roadmap for 80% use case of web forms in core or SMTP supporting core or introduce outside in quick edit pattern to core sample content, project browser, those kinds of things. So the idea of the ideas queue is to discuss high level proposals and then if there's and then have some agreement on whether they fit core or whether they are better done in contrib. So you can get very early feedback on your plans, your ideas and then you can work your idea to a prototype and then work a prototype to a plan and then move forward from there. So all this work is theoretically happening in the ideas queue. As I said, we just launched this a week ago so we'll work out how this exactly works. And then if this is approved for core, then you're gonna move on to the core queue and you're gonna do the implementation. If it's not approved for core, it does not mean that it's a bad idea at all. It may not be an idea for core, right? It may be a very good idea for contrib that you wanna work on, but this basically feedback that it's not not the core committers believe that it's not suitable for core. And so if it's approved for core, then you would work on building it out and that may involve stable APIs and stable features or it may involve experimental modules, depending on your idea and the implementation plan. So this may use either tools, tool sets that we have in core. So if it's a huge thing that requires multiple steps and a lot of user feedback, it may be more suitable for experimental modules. If it's a simpler idea, maybe SMTP in core is simple, I don't know, from one line you can never tell, then it may be a stable improvement right away. And then if it's stable enough, then you get happily ever after and then it's there and then everybody's happy with where it's at. So as we've said, this is the SD experimental module structure goes. This may still go out of core if it fails or if it's not suitable or if we find a better solution. But if it happens to prove itself, then it will make sure and be stable in core. Okay, so this was the informational part of the session. And then I have a few trigger questions, but before I have trigger questions, then any feedback or anything I missed or any particular things that people came here to discuss? Do you think that a Drupal 8 to Drupal 9 will potentially take longer than Drupal 7 to Drupal 8 because we don't really need Drupal 9? We're just gonna add features in point releases and iterate on that. And it's always gonna be non API breaking and everyone's always gonna be happy. And potentially we don't need Drupal 9 until we need to drop things. And I know with a lot of other things like some of the symphony components, for example, they change the major release number and drop all of the deprecated stuff, but it's still pretty much the same release. It's all just works. So do you think the Drupal 9 process will be very different to the Drupal 8 process? I think so, yeah. So basically I think there's two different triggers. By the way, that was one of my trigger questions, so thank you. So basically there's two reasons for doing Drupal 9. Either we have too much crap that we wanna get rid of or we have changes that we need to make that we cannot make in a backwards compatible way. So those are the two things. And I don't think we are there yet that we have too much stuff that we wanna remove. We are still deprecating things and we'll still have more to deprecate before it's becoming too much. As for backwards incompatible changes required, I just talked to Theodore, a JavaScript maintainer, and he says that they had a meeting where they figured out that it's very hard to do testable, unit testable JavaScript and make some of the changes that they need to make to modernize the JavaScript system without substantially breaking backwards compatibility. So there may be some things like that that make it impossible to do in eight or maybe we need to scale back our ambitions in those areas for it to happen. So that may make Drupal 9 sooner than we expect, but I don't expect Drupal 9 to be very soon. Hi, thanks for the talk. I was wondering if you have like a suggestion for an architectural change in core, would that go into the issues project like a suggestion? Yeah, so the ideas queue is for major changes in core that may affect the product, that may involve the product manager or the framework manager. So there's like nice definitions on Drupal.org and what the product manager and the framework managers do that are basic changes that are basically affecting the major systems in Drupal. So if you have proposals like that, then that would involve the ideas queue. It also gets more attention from core committers, I guess, because that's a higher level thing that they are looking at. So if you believe that would affect or would require the framework manager, then I suggest you post it there. And the worst thing that happens is you get a quick move of the issue to the core queue. So this is kind of a follow up to the previous question. Are we recording when things get deprecated? So we could ideally start, sorry, dropping support for deprecated stuff. It got deprecated like a long time ago and people have more chances to not be using and they then keep doing that instead of doing a major release that drops support for everything at once. Yes, we are. If I find the right, not drupal.ex.org. So we have a change list on drupal.org that we keep updated for new releases. So change records for Drupal core and you say you are interested in 8.2 changes. 8. Well, unfortunately they are not consistently named. But if you're looking at 8.2.0 changes, then you gotta tell you about a bunch of things that changed and some of them involve deprecation of things like select interface write join deprecated or file cache can be disabled completely now, et cetera, et cetera. Migrate map, migrate ID map interface, lookup destination ID deprecated, et cetera. So we are posting change entries for these. We may not be posting change entries for everything, but we are always updating the API documentation as well with the app deprecated. So if you look on api.drupal.org for that or just search the code base for deprecated things. That also tells you if you use an ID like PHP storm or some other IDs, they're gonna cross over the code that you are trying to invoke if it's deprecated. So like if you look at the code, it would be visually evident that you're using something that's deprecated. Right, that's my point. So if you've been seeing this scratched thing in PHP storm for long enough, chances are that after maybe a year and a half, you stopped using that. So that one is safer to remove. Something like maybe after 8.9, we start dropping support for things that got deprecated in 8.0. That would not be semantic versioning. Well, maybe after 8.9, we can call it 9.00. And then 9.00, if you do that, yes. We could start deprecating things quicker without high chances of requiring multiple updates inside. Yeah, in other words, I think your point is the sooner we release 9.9, the less APIs we change. So the easier for people to update their code to 9.9, in other words. So then if we are not releasing 9.9 so soon, then there's gonna be a lot of changes that people may not have updated in their contributed models and there's gonna be a lot of change. Yes, that's true. That's still a danger of that. We don't have a mechanism to force anyone to not use deprecated things. So, yeah. And the other thing that I've had a trigger question for, I'm interested in people's opinions is whether we are stabilizing experimental modules enough because that's the other problem of, we have all those experimental modules and we now have this danger sign that we're gonna remove your experimental modules if they're not stable soon enough, but is that enough to incentivize people to work on them? I don't know. Or if you wanna talk about something else, that's fine. There was no direct answer to this one. Well, I was just gonna go back to the thing about 9.9 and other versions and should we create the major versions quicker? Should we look at scheduling that so every sort of three years, four years, put a time on it that we do a major version and make sure there's an upgrade path? And if we make sure there's an upgrade path between these major releases, do we still need to support the previous releases? Will we still need to support Drupal 8 when Drupal 9 is out? Do we do it like we do the minor releases now as soon as the next minor release is out, we stop supporting the previous minor release? Should we start doing that with major releases as long as there's an upgrade path? Well, if we do them very, very soon, then we maybe not need to, but the current plan is that we would because there's still a requirement for all the modules to be updated, right? And all the data to be migrated. So there is the Drupal core release cycle thing overview that has a nice picture of this. So the plan, the version numbers should not be taken indicative of actual plans, ignored the numbers. So the plan is once Drupal 9 is started, then we have a long-term support release of the last Drupal 8 version before that. And the reason for that is because we make all of these API changes between these two, then people will need time, they don't have time if we immediately drop support for Drupal 8 previous to update to the latest version. So we need to give them some time, maybe not so much time, maybe not until Drupal 10, but we need to give them some time to be able to do those code and data updates for Drupal 9 and then the same later on. So I don't think that we can immediately drop the support, but it may not need to be this long. I agree with that. First of all, I actually have a module for usability that has been moved to Drupal 9 already. So obviously I would be happy if we can move to 9 faster than later. But I'm also wondering about as site builders who don't do coding, we still come up with ideas that would be useful to have. And I'm wondering whether in this ideas process there's also space for that, because otherwise I need to come with my idea and also lobby around to find a developer to actually put that into practice. And I wonder whether there is some way of encouraging people who can't actually do the coding to still come forward with their ideas. Yes, I think we should promote this far and wide and get people submit their ideas and have a lot of ideas. Not everybody agrees with that. Some people agree that we, some people say that we already work on a lot of things. But I think the more ideas, the better we can figure out, we can then figure out the best ideas and then maybe find people to solve them. There's no, we don't have a pool of developers ready to deploy on an idea. So we don't have a solution for that. But I think as much as there is a value in submitting a bug report, even if you have no idea how to fix it, there's even more value in submitting an idea of improvement so that we can, we have input on things that we may have never thought about because we just don't have that perspective. So yes. I just want to add for, supporting older versions, we're only talking about security patches for those. So that is a difference to what? That's not what this says, bug fixes up until this time in security. Oh, okay, I'm sorry. I mean, yeah, not forever. It's not for the entire, you know, lifetime. Yeah. So this says LTS is including bug fixes and then security is coming on later. But this figure was made a long time ago. And as I said, there's like, the versions are not indicative. So like, do not expect that Drupal 9 is starting next January or something because that's when this would be now. No, I would be surprised. So just to note about Drupal 7 support, the idea would be to drop that a few months after 9.0 access released. So that also means we probably won't get to, as someone said, 8.9.0x. Or you reckon we might? Because, I mean, we can go however long we want with them. With the money. You're doing it so good, you can stop working. Yeah. But then I got the impression also from, well, let's say, Tim Plunkett. He said, no, we're not gonna get to 8.9.0x. We'll get to Drupal 9 before that. But then that's just an anecdote. I guess we just don't know. We don't know. No one knows. I don't think we know. I don't think we know. So my personal opinion, which is not official, is that we did not accumulate enough crap yet that we want to remove. And we did encounter things that we need API changes for, which is a very, very different thing because it requires us to make changes to 9.0 that we're never gonna make to 8.0. So it will require some window in 9.0 that we work on things that never gonna get into 8.0. And that may take some time, depending on the extent of API changes we want to do. With an hopefully the upgrade path from 8.0 to 9.0 will be a lot easier. Yes, because for the modules that kept updating their code to the latest 8.0 version because they see things that are replicated and they adapt, they will mostly work with Drupal 9.0 except those API changes that we needed to make because they were not possible in 8.0. Maybe an unrelated point of discussion, but I was wondering if at some point we could do like harder deprecation than merely putting a deprecated in there. Just to push people to get rid of those deprecated. What do you mean? Calls, such as something that makes test fail if they use deprecated functions after the LTS? Yeah, that's... He needed warnings. Yeah, I think symphony, they do some kind of notice if you use deprecated functions. Mm-hmm, yeah, that sounds good, yeah. That would be nice. Or we could put like a shameful message in the project page. Sorry. So... I don't know. That was a joke, obviously. Yeah, yeah. So my question is, it seems that the whole idea of the experimental modules is to the goal of adding visibility in these promoted modules. Is that a correct statement? Yes, because we could work on the same things in contrib theoretically, but we want to set these up as things that will be baseline Drupal like if content moderation is baseline Drupal, then people will need to work with a possibility that is there instead of, may or may not be aware that there may be a contrib content moderation solution. So it's more visibility, but we eventually want them to be baseline Drupal, so that's why we put them there. So I would add that I think that one of the other reasons why we decided to put the experimental modules in core instead of just in contrib is because in order for things to get committed to an experimental module, core committers have to commit them. So it's a way of having that core committer view continually involved in the process versus if it was a contrib project, the committers don't necessarily have to be core committers. So I guess we could decide to make a special kind of contrib thing where the committers are core committers, but the idea was is that these incremental differences that you're doing through the developmental process of the experimental modules are getting frequent feedback from the core committers. So as you're investing all this time, you're doing it in a way which is helping you prepare for getting included into core with less surprises that you're going to get pushed back when you actually try and ask to get in. Yes, very good point. Thank you. You're very right. So you get a core committer feedback in the idea phase. You get core committer feedback in the prototype phase. You get core committer feedback for your plan. They approve your plan and then they review every single patch that you do. So instead of you building it out up until this point, spending it all the time, all the research and everything, and then core committers looking at your whole big blob of thing, they get to provide you feedback in much smaller chunks, much earlier. So you get to know if it makes sense to build this. You get to know what's important to build in here, what they're going to consider as a minimum viable implementation of this. So you can get to build that and then you get that feedback and you get it in core. That seems to be like a beginner question to have something else. Yeah, so my point is can we have some other method of helping discoverability of outstanding modules that may not necessarily be fit for baseline Drupal without having to put them in core so people will try them with discover issues. So we maybe supply something in core that helps find these modules that we think are outstanding but not really for every core installation. So one of the ideas in the Ideas queue, once I get there in my fancy animation, is add project browser, which is a way to expose projects on your Drupal site that you may want to install and that could highlight new modules or modules by whatever criteria to use. So that was idea three years ago or something that four years ago almost that we wanted to have and now it's in the Ideas queue and we can discuss it on that level whether we even won this or not because some people worked on some patch and then some people didn't agree that it's worthy for a core and so we can discuss it on the level now where we can figure out if we want to do more work on that or not. I just want to add to the sort of weird and wrong thing I said earlier is that I think that what I would like is that if we could make the transition to nine so much less painful that it makes the notion of an LTS not needed or not, I don't want to say not needed, but perhaps it would only go for as long as the next feature release or something because it would be so trivial to sort of upgrade implementations of everything that the whole community can move on because I think it's very draining to support two entire versions of Drupal. Yeah, absolutely. So the way to there is if we can make every change backwards compatible somehow if we can figure somehow crack that code that would be amazing because then all the Drupal nine would be the same as the previous Drupal eight version and the number would just remove the backwards compatible layers. If we can figure that out, I don't know. There's a whole lot of things going on for me to state that in any way. But as long as we need backwards compatible breaking changes in line, the danger is also there that we may want to do other things and then it may drag for some time. So I think based on our previous history, it may cause us problems if we go in there and just start working on nine in that bubble again and do that. So if we can limit the scope of those changes at least or even better if we can eliminate entirely the need for backwards incompatible changes that are unique to Drupal nine, that would be nice. So speaking of upgrading from eight to nine. So to get from six to seven and six to eight and seven to eight, right now that's migration. So are people thinking that we do eight to nine with migration? Because people have been talking about upgrading, not migrating. Are we not thinking about that? Or have people thought about that? I don't know. So I think it depends because we drop security support for every previous eight version. So theoretically in an ideal world, everybody is in the latest eight version because that's the only version we support. So theoretically, ideally, we only need to support the latest eight version to nine, which should be the same data structure in this ideal scenario. They should use the same database and everything and same configuration structures. Only the APIs would change. So only the module code would need to change. None of the data structure would need to change. That's the ideal scenario for a pain less upgrade path. So you don't need the upgrade path or the migrate path. I guess it depends on how API breaking, the API breaking changes are. And mainly schema breaking changes. For example, we're looking already at making other entity types for a visionable and that requires a huge schema change. And that's not considered an API breaking change. So it's possible in a minor release now, but we need to provide an upgrade path. The upgrade path is currently hundreds of lines of code in an update hook. But we are doing this in Contrib already using the migrate module. So we're using migrate to do an upgrade path. So we're using migrate to migrate everything to a temporary store, change the schema and then migrate everything back into core. So we could potentially use migrate to do the upgrade path. But yeah, it depends. Yeah, but I mean, if once we have that in core in eight something, then if we only drop API changes from the last eight to nine, we don't introduce new API changes, then we'll not need to run into things like that. So what if in nine we provide big schema changes, big API changes, then it will be possible to do an upgrade path, but it might be an ugly upgrade path that might make migrate easier to do than upgrade. And not just easier, but more stable. I was talking earlier today that if we do hundreds of lines in an upgrade path, is that hundreds of lines of new code more stable than using an experimental module which migrate still is or not? Yeah, what's more stable new code or an alpha experimental module? I don't have the answer for that. Okay, so that was it. So if you want to work on some of these changes, then there's going to be amazing teams working on these at the general sprints. And I'm sure that there's going to be issues that the mentored core sprints and the first time sprint workshops will also get involved with in a lot of these areas that we're working on. And if you have feedback, positive, negative, something about this session, then I would love to hear that from you. Thank you. I'm going to go back to the evaluation submission form. And if there's no other discussion item, then thank you for coming. Just one small thing. You can leave if you want. 777 we recently changed to not exactly semantic versioning, but we do plan to do some kind of major release every six to nine months. And then we're going to do some new features that might already be in Drupal 8 or Drupal 8 in another form. So just wanted to quickly mention that. Good.