 Um, this is Drupal 8 or Drupal is changing quickly, how and why? So hopefully you're here for that or maybe you're here for the commerce stuff and stay over. Appreciate that too. Um, so I just actually am putting the session, the survey question here in case I like crammed for a time at the end and forget to remind you. Uh, please take the survey after this and find it on the schedule then you can take a survey. Um, let them know how the session was. Um, so my name's Ted Bowman. I work at Acquia at the office of the CTO, Octo. Um, and uh, I'm Ted Bow on Twitter and Drupal.org. So what I do as part of my work at Octo, I'm a core developer working on decoupled and UX experience for Drupal 8 and I'm the maintainer of the settings tray module, the experimental core module and that's kind of why I uh, one reason I thought about doing this session is because I've, I've sort of found out some stuff about the whole release process that I didn't know before and I talked to other people and they also didn't know it before though I thought, so I thought there's probably a lot of people who don't know this stuff and it's good to know. Um, working on the core REST module. Um, Gabor is here, I want to thank him for, he made, I, I took some of his graphics from previous slides. Actually, and I saw a session he did that was a core conversation that related to this and I'm sort of thinking this as a core conversation for people who aren't involved in core. So, um, who are you? So how many people here are say a developer? How many people here a theme or how many people are like a site business owner that uses Drupal? Okay, so let's show that. Um, how many people are cute while, while they're puppy? No. Um, how many people are totally new to Drupal? Okay, so not that many. How many people are new to Drupal 8 or haven't used Drupal 8 yet? Okay, cool. So a lot of people may be familiar with Drupal but not so much necessarily working in Drupal 8 yet or at least not everybody. Um, so let's talk about Drupal core development cycles. Please don't leave. Let's talk about why Drupal core development cycles might actually matter to you. Um, so there's a lot of, been a lot of big changes since Drupal 7 and I'm not sure about the Drupal, uh, sort of core release, release cycle since before Drupal 5 because I got involved with Drupal around the, the late part of Drupal 5 and so for me, from my perspective there's been a lot of changes since that time. Um, in which I think is a good thing. Um, so we're going to talk about release schedules, uh, supported versions, uh, new features and what's up with Drupal 9. So the release schedule before Drupal 8, if we look at this, um, so from Drupal 4 to Drupal 5 it took 8 months to develop. Drupal 5 to Drupal 6 took 13 months. Drupal 6 to Drupal 7 took 25 months. Anybody want to guess if that's going to go up or down for Drupal, from Drupal 7 to Drupal 8? Uh, 49 months. So, you know, this is, uh, definitely I think I, you know, I wasn't involved with core development, um, in the Drupal 8 cycle or the Drupal 7 to Drupal 8 cycle except just really, really in a, a small, actually my monitor is not, uh, I just noticed that it's not including the whole thing that I'm seeing you aren't seeing. So bear with me a second. You're still not seeing everything I'm seeing. Not. Hmm. What's that? So those are my two options. I feel like this one is better. No, the other one's better. Yeah. Okay. So, uh, yeah. I will, above it says months from previous versions. So basically I think you get the idea from the graph without seeing the actual label that this is something we probably don't want to continue. Um, so the least, least cycle pre-Drupal 8 was there really wasn't a release cycle, there wasn't a release schedule let's say. Um, no guarantees. It's, you know, it's ready when it's ready. Which is good in a way that, you know, not releasing software before it's ready is a good thing. Um, but then, you know, after the core was released then you have to play the contrib module waiting game where, you know, uh, Drupal 7's released and then you have to wait for everything to, uh, all the contrib to get ready for Drupal 7, Drupal 8's released. Uh, some of that hopefully we're at the end of that cycle now where we're waiting for stuff to, to get ready from Drupal 7 to Drupal 8. So we'll talk about more about this later. Um, oh, wrong way. Um, so which leads to, uh, Angie or various people would, you know, blog posts about when is stuff going to be ready? Sort of trying to get the community involved and let's get stuff ready for the next version. Um, this is Drupal 8, blog posts similar, similar about like the status of the top 100 modules for, uh, for Drupal 8. Are they ready or not? Um, so you know, why does this matter? Why is this sort of graph not where we want to go in the future? Um, you know, basically the web moves fast, like web technologies are moving fast. We want to add, um, you know, things that we see other websites or other systems using. We want to add to Drupal, uh, you know, our customers or the people who use Drupal expect that. Um, but Drupal was moving slowly. Um, and a lot of it was like, you know, core moves slowly, uh, contrib maybe moves faster, a lot more innovation in the past was happening in TRIB. I mean, obviously a lot of innovation happens in TRIB, but um, one way again. Uh, so release schedule post Drupal 8, um, we actually have scheduled releases, um, every six months. So, let's look at that, you know, we've already doing the schedule releases, uh, 8.0.0 came out in November 2015, then we have, um, in April 2016, 8.1.0, 8.2 came out in October 5th, 2016, and then just recently 8.3.0 came out. So, this is something that's happening and it has been happening, um, and we've been hitting pretty good. The Drupal community has been, uh, you know, getting these roughly on the six month mark there. Um, so the current versions right now for Drupal are 7.54 and 7, or 8.31. So, you'll notice a little difference here is we have this, um, you know, just two portions of the versioning system in 7, but 3 in 8.8. So, what's up with this last part here? Um, this is semantic versioning. It's a software release numbering system, often called SimVir, and it deals with the public API. So, we have 8 being our major version, 3 being minor, and 1 is the patch release. So, this is what is out there now. Um, so this is where there's bug fixes, security fixes, so as, um, go along you see problems in Drupal Core, they get fixed, they get added in the patch releases. Um, Drupal, the major version is where you have backward compatibility changes going, uh, back, breaking backwards compatibility changes that happen. So, obviously like Drupal 7 came, uh, and then Drupal 8, and obviously you can't run the same modules that might be different somewhat for Drupal 9. But the idea is, um, you shouldn't really have to think too much about contrib in these, uh, minor versions in the middle. But, uh, in this minor versions here is where we can add features without backwards compatibility breaking changes. So, Dries talked today about a lot of experimental modules, and this is where in the minor releases you can look at the release notes and say, oh, this, you know, there's a new module added, um, or modules move from certain, like alpha to beta, uh, so let's look more about that. So every six months, we have these releases, and then 8.0 comes out, and then 8.1, and then 8.2, 8.0, 0.3, and then at six months later, about 8.1.0 will come out. And then we'll go through the same process there, and then move over here in the same process. Um, so an important thing to know is, so this, we have our minor patch patch release, minor patch patch patch patch patch patch patch patch. And at some point we, six months later, we have another minor patch. So this, you'll see this cycle going on throughout, uh, the Drupal 8 release cycle. Um, but then we have this minor release quality assurance time. So since we're gonna be adding potentially new features, um, a lot of it's gonna be an experimental modules that's, but that's not exclusive. Um, that it's gonna be experimental modules. Um, is 8.3, or every time you have a 3, you have 8.0 release, there's gonna be a beta and then an RC. So for example, 8.3 came out, there was an alpha on February 1st, and then a beta 1 for 8.30 on February 22nd, and then a release candidate, and then finally 8.3.0. So, you know, if you have a site and it's running on Drupal 8 and you think, well, I see some new stuff coming out, you'll probably wanna test your site. Um, you know, especially when the RC comes out, if you have a development workflow where you can actually split off and, and you know, uh, make a new environment, it might be a good idea to test against the next minor release version there. Um, and also supported versions. So, um, we get the support on these minor releases, but then when we move to 8.0.1, um, then we're not gonna have support on the old version. So it's basically, I mean, if I, it would make more sense if we flatten this out, because it's really a line going down, that you basically don't want to, to be on those old versions, you wanna update the sites. And because, you know, we're trying to keep backwards compatibility, breaking changes out of this cycle here, you really wanna be keeping up with that. Um, there was actually a security release last week, I think, that was against the 8.3 branch, that's why 8.3.1 came out. And there was a, because it was such a potential security problem, there was a patch against the 8.2, but that's not, I think usually how it's gonna happen. And also because it was just, 8.3 had just come out. Um, so if you're running 8.1, uh, .10, oh no, you're not, you know, on a supported version of Drupal. So you wanna update your site now. Oh wait. Okay, so let's talk about new core features. Um, new features are exciting, potentially scary, you know, bugs and new features. Um, so new features before Drupal 8, usually for most part meant went around with major releases. So Drupal 6, and for instance, added the drag and drop interface, um, the update status module. Uh, Drupal 7 added custom fields, what used to be CCK, uh, the overlay module, image styles, and then Drupal 8, that 49 month, uh, between versions, actually we hold, we got a whole lot for that, you know, views, content and configuration translation, configuration management, um, CK adders. So a whole bunch of good stuff obviously happened within those 49 months. Um, so new features, obviously, you know, new bugs, possibly new security holes. Um, so new features in Drupal 8, we've introduced the idea of experimental modules. So experimental modules, they're not yet stable, but they're included in core. You'll get a warning when you turn them on, say, do not run them in production. And they also have their own, uh, release cycle that is, sort of, they will be marked in these alpha beta release candidates stable in the minor versions of Drupal, but they don't necessarily, um, you could potentially have, uh, something go in at beta, at beta state here. Um, they could be removed though, let's say we, I mean, the idea that they're experimental is they're not done, they're not stable and potentially, you know, people in core could work on them and we think, you know, after actually really doing this more, we realize maybe this is not a good match for core. Um, they could be removed, but there is a possibility, and I don't think anything's actually been removed, experimental module in, uh, Drupal 8 yet to say, oh, this is just not going to go into core after it's started the experimental process. But potentially, um, if it is removed and, you know, some people really like it, it's just something that doesn't seem like it's going to make it in core. Um, it could go to contrib. Um, so right now these are the alpha level, uh, experimental modules, uh, settings tray I'm working on, there's inline form errors, the migrate UI, content moderation, actually these aren't all of them, these are just sort of sampling. Um, I think this is actually the only beta level, uh, experimental module in Drupal 8-3, uh, the migrate module. And then we have big pipe module, which is no longer experimental module, but it did go through that process. It was an experimental module, and then made it to stable. So, um, I haven't tried this, but I'm assuming you turn on big pipe now, you will not get a warning that says this is experimental module. Um, you know, 8-2 you would have got that. So feel free to turn that on in production now. Um, trees give a demo, it's really, you know, awesome, uh, great improvement for your users. Um, so experimental modules again are not stable, do not run them in production. But you're probably thinking, you know, really can I run them in production? I probably can run them in production, right? Uh, no. So actually I just, I got rid of my last slide that was in this and I had taken a picture this morning and I was like, I'll swap this out cause it was awesome. Um, you know, experimental module advisory do not, you know, do not use in production. So, uh, you know, potential security problems, potential data loss. Um, you know, people have asked me like, okay, if I really shouldn't use them in production, what's the point of them being in core? You know, one, I mean, one thing is a lot of people when they're making sites, it's like a multi-month, you know, half year long process. So, um, it's really, you know, you may want to work with the settings tray module in your site if you're developing a site that is really not going to be, uh, production ready until 2018. Um, so oftentimes you're developing a site that's going to be a live site in production and it's really important and you wouldn't want data loss, you wouldn't want, uh, security holes but this site is only developers are working on it right now. It's not live to the world. Um, so let's say maybe you have an idea for something you would like to get into Drupal Core. Um, there is a project called the Drupal Core Ideas Project and this is like a, um, like a module page or a theme page. It has an issue, um, I lost my slide order here. It has an issue queue. You can, um, you can propose an issue. Uh, it can go through the whole like needs work, uh, RTBC reviewed and tested by community. So, the idea is that we don't, you could just add something to core and a lot of things that aren't like, so big ideas don't necessarily have to go through the issue queue. But if you had a big idea for something in core, you could spend like a month writing code for it and then you could have the, the patch writing and post it out to on the Drupal Core issue queue and then maybe everybody will say, you know, hey, this is a really bad idea or hey, a bunch of people have been working on this that you didn't know about and we're already doing this somewhere else. Um, so the idea is you post it out to the issue queue, it can sort of get, uh, backing behind it, can get a lot of, um, plan, planning before you actually go and start writing code. Um, cause a lot of us, you know, in our day jobs, we probably don't just get a client and then just start writing code for them immediately. You know, we see what they actually need, what features actually make sense. Um, so this is the issue queue. That's going the wrong direction. So example ideas or these are issues that are actually out on the issue queue right now, the media initiatives, essentials, um, out of the box experience initiative. Um, one idea is to remove the band module from core and one idea is to put path auto in core. So these aren't things necessarily that are going to happen, but these are things that are ideas in the issue queue and right now people are debating the merits of these things. So if you have a, you know, a really, um, uh, strong opinion about maybe I love the band module, don't take it out of core. You might want to, you know, go in and, uh, go into that issue or if you think path auto is like, oh my god, that should have been in core like five years ago. You might want to weigh in on that issue. Um, so the idea is on the issue queue, we would, somebody who come in with an idea might build a prototype. It does not have to be, uh, Drupal code. It doesn't necessarily even have to be code. It could be like a UX mock up. Uh, there'd be a plan around that and you'd sort of go in that cycle until you get sign off and people, and it goes from reviewed, tested community to I think fixed or maybe it would move over to the Drupal core issue queue, but basically before you start writing Drupal code, you would go through this process. But then it would get approved and then you'd go over to the Drupal issue queue, build, and happiness. Um, so why ideas and not code right away? Get buy in from maintainers and committers. Um, plan before the implementation and maybe you want to focus on UX before you actually start writing Drupal code and a number of other reasons probably that I'm not thinking of. Um, so how can you help? Um, you can support new features. Um, you could help with existing experimental modules that are in the Drupal core issue queue. Um, UX and testing and planning for stuff in the ideas queue. Uh, you could promote existing, uh, experimental modules, write blog posts about it, do tutorials about how to use them, of course with the caveat that's saying they're experimental. Um, you could sponsor sprints and developers who are working on experimental modules or in other initiatives. Um, and usually this slide is for the end, but I just wanted to promote this slide now, this, which actually I'm almost at the end, uh, join us for the contribution sprints, um, because I know I'll be working on the settings tray module and I'm sure a lot of other people will be working on some of these experimental modules. Um, so you don't necessarily have to code a lot, you know, pretty much if you're interested in helping out, you know, show up either if you're interested in helping out specifically with the stuff that I'm talking about or in general Drupal core or contrived show up on Friday. Um, so what about Drupal 9? Um, Drupal 9 is basically gonna be removing Drupal 8 deprecated code. Um, so it could be almost identical to the last release of Drupal 8. Um, so what's that mean? So potentially modules could be compatible with both Drupal 8 and Drupal 9. If they're not using any Drupal 8 compatible, uh, deprecated code, that same code could potentially run on a Drupal 9 site. Um, it also means that we probably won't be needing to do a complete site rebuild between Drupal 8 and Drupal 9. Um, because if you have your contrived modules and your custom code aren't using deprecated code, you could pretty much have the same site working Drupal 9. This is a ways off so we'll see, but that from my, that seems like that's a possibility. Um, the other thing I think that it means is don't wait for Drupal 9. So I know when Drupal 8 came out, I talked to a lot of people and they're thinking, you know, Drupal core, two major versions are supported at a time. So I have a Drupal 7 site and I don't want to build on Drupal 8 and then Drupal 9 come out and then I do two major rebuilds. Because the 8 to 9 potentially will not be a major rebuild, there might be incentive now to not wait for Drupal 8. So not skip 8 and basically build on Drupal 8 now. And when Drupal 9 comes along, it won't be the same pain that 7 to 8 might have been for you. Um, other possibilities, these are just things I'm thinking of, not really other, that I've heard other places is, you could have kind of compatibility badges. So you could have an automated system on Drupal.org that says, you know, this module is compatible with Drupal 9. And we would know that because it's not using any deprecated code. Um, modules tested pre Drupal 9. So we could have Drupal 9 coming out and we could actually start to run tests on all contributed modules against Drupal 9 to see if they fail or not. Um, we could have automatic compatibility testing. Um, another thing I thought is we could have a Drush command that says Drush upgrade test core 9. Say, hey, Drupal 9 is coming. Check to see if my site uses any deprecated code that will not be available in Drupal 9. This doesn't exist. I just thought, you know, it's an idea. Um, and the contrib module waiting game. I'm not sure if it will be totally gone, but it could be a whole lot better because you know, every contrib module maintainer does not have to rewrite their code for Drupal, um, for Drupal 9. So potentially if you're keeping up, and I know I've been a contrib module maintainer in the past, I know it's hard to do this, but potentially if you're keeping up and you can make sure that you're not using any of that deprecated code that's currently and will be in the future in Drupal 8, then your module potentially will be just ready for Drupal 9. Um, I think we have five minutes. I'm just gonna remind you about the survey again. Um, if the next speaker's here and I should be gone, let me know. But otherwise questions? Five minutes questions? Yeah, so a lot of stuff potentially, a lot of things it's not changed, like the media stuff going in to Drupal 8. Um, it's potentially I think going in as the media entity being stable, but like the media browser being experimental. And those things live and contrib now. So it's not like the complete idea of, of, of innovation and contrib and then moving into core is, is not gone with this idea. Um, there have been some, some things I think like in line, in, in line form errors that have, um, did not, I don't think lives and contrib. But I mean we've always had stuff I think, I think there's always been stuff that it's gone into core and without necessarily being in, in contrib. It just went in in major cycles. And now with semantic versioning we have the ability to put it in in minor cycles. So I don't think, I mean I agree that I hope innovation keeps happening in contrib. But it's not, um, it's not like we never, and I'm pretty new to Drupal core develop. So I, I can't say this for sure, but it's not been that we, that things haven't been added to Drupal core without going to the contrib first. It's just, it always happened on major releases and now it can possibly happen on minor releases. Yep. Yeah. But I think, I think right now the idea is that, I mean basically like if you plan to keep it over in Drupal 9 then by definition it's not deprecated. So I think that would be more in this, a decision of we can't deprecate everything or it would be by definition a rebuild. So I think it's more just like a be careful what we deprecate and don't just like go through and just like let's just mark everything deprecated before Drupal 9 so we can rebuild Drupal 8 so Drupal 9 can be a total rebuild again. But yeah I, I see what you mean it would be nice but then it's like you get into the point of deprecated means deprecated and they're going to be not like the major reversions, inversions are where it's, where it's torn out and also I think just the decision making process if you didn't have that cut off to say this is when we do it then yeah it would be hard. Yep. Just is, I think it's on. Just to be clear if I use a Drupal 8.0 module at 8.9 it's not going to be broken. I just want to make sure I understand the semantic burden. That is, that is the idea. Yeah. You sounded a little you know not. Yeah so that is not so the API as far as the API is concerned that is true but there's a lot of things that are not covered in the API like say I think render arrays or forms. So if you have a module that relies on the form being a particular way and it does a form alter and if it can't do the form alter in that way to work and in Drupal 8.8 that form changes then the contrib module has to update that. I guess more what we're saying is like the application programming interface like the object oriented interfaces and stuff like that. That's what we sort of can guarantee won't change. So there is actually a backwards compatibility. I'll put it on the session notes that goes into DSA on what's covered and what's not covered. So yeah note it's not a like hard, fast guarantee that if somebody writes an 8.00 module it will run an 8.99.0. Okay thank you. Yeah. And that's one of the sort of reasons I think also for testing those release candidates of the minor releases with your particular site or if you're a contrib module with your with your particular contrib module. Alright well again the survey and the the contribution spends on Friday. If you have questions I'll be out there or feel free to ping me on Twitter or Drupal.org or find me in the hall or whatever. Thanks.