 This is the road to 8.1. We're talking about Drupal release cycle management So for those who don't know me yet. Oh, there's Jess. I was wondering where she was uh, she was gonna show up We just started you haven't missed anything yet My name is Larry Garfield or Crell online senior architect with Palantir web services lead for Drupal 8s Fig representative you've probably heard this all before I do a lot of Drupal and I've been heavily involved in Drupal 8. So enough of that and I want to talk about The upcoming Drupal 8 that is going to be awesome and we all know this and there's still a lot of work to do and we know This but we need to be thinking long term. So specifically I want to talk about Drupal 8.1 Which is going to be a thing? So Drupal 8 is going to go down as Drupal's longest release cycle in history and For the love of God, let's please never do this again. Let Drupal 8 stand, you know, keep that record for a long long time Now I'm gonna say that this probably looking at four-year cycle overall was necessary because We jumped Drupal ahead about eight years in terms of PHP development practices and software engineering practices so, you know doing that in Four years actually three since we didn't even start that heavy work until a year after Drupal 7 launched Pulling that off in three years is pretty good. So round of applause for the core team that's managed to pull that off But we really don't need to do that level of overhaul every core version There are you know things we want to change every version. That's fine We want to involve you want to stay relevant, but we don't need to rewrite everything every version and part of the problem that we ran into is As usual, we don't know what the length of a release cycle is We you know release a Drupal version and we start work on the next core version immediately and we work on it until Dries says stop Whenever that is and sometimes we keep on going even after he says stop and we just don't listen to him. So What that leads to is a lot of big uneven plans of different lengths and different complexities that may or may not be possible to do part way Which means the release cycle gets longer and so more you get more uneven plans and it just becomes a big muddle And this is a problem. Most people acknowledge this a problem And so it's Drupal con Prague. We had a core conversation where we said let's try doing something else instead and I put forth a proposal for a new release cycle, which I was only giving a presentation, but it had been talked about before and Pretty much everyone was on board with immediately, which is great. So yeah team And so after some discussion This is the the plan for the Drupal 8 release cycle. This is already a done deal this part So at some point we're going to release 8.0 point zero not 8.0 8.0 point zero and This will be as soon as we finish all of those critical. So go help with that And then a month later we release 8.01 bug fix security fix and so forth just like we do now We're just adding a zero in the middle And then another one a month later and so on and so on But six months in we have a new release 8.1 that does have new functionality. We will actually have feature adding releases for Drupal 8 And we're targeting every six months for that And then I'm on seven eight point one point one again bug fixes security fixes the normal maintenance type stuff At the 12 month mark. We have an eight point two Then bug fixes on that and so on and so on for as long as we decide we can still roll with that architecture We're probably looking at eight point three eight point four being where we eventually stop and say all right That's an LTS release meaning no more new feature releases just security that will keep on going indefinitely and Then we can start looking at Drupal 9 and Drupal 9 I'm Recommending we focus just on those things that would be API changes Not functionality changes not just adding capabilities in Drupal 9 so that we can keep the drip that 9 cycle short so there's more to it about you know security maintenance and Life by life cycle of Drupal 6 and so forth. I'm not going to get into that here It's not relevant, but this is at this point essentially a done deal for how Drupal 8 is going to work release wise Is this is there anyone here for whom this is not old news? Good and we're going to make that statements that in those minor releases in 8 1 and 8 2 and 8 3 We are not going to break API's on contrib developers Good that means people actually want to upgrade which is an advantage For some definition of API What is an API so that we are going to not break it? That's a kind of important question Sometime last year if you ask to the Drupal con IRC, but what an API was this was its answer As long as that's our definition of API none of this works Let's be clear if API is the code exists We cannot do anything in this regard so we need a different way to define what an API is Our old API definition in practice worked more like this any line that begins with the word function is part of the API Except for those that remark as private because they begin with an underscore Except that sometimes that was the only way to accomplish something and so we couldn't change those either because we knew people Were relying on it in contrib. This is not a good definition of an API. Oh Yeah, and if it was in an array it was an API which again means you can't do diddly squat The reason Drupal has always had this policy of between every release we do we're allowed to break API's is We had an architecture that didn't let us define something as API and something not so we couldn't evolve the system without breaking Something somewhere potentially and so we were very conservative about that and said we either have You can't do anything or you can break anything and that dichotomy is a huge problem, especially for contrib developers Actually, let me pause a moment. Who here identified themselves as a core developer? Who here would identify themselves as a contrib developer? Okay, so pretty good split that's awesome. I knew architecture in Drupal 8 with all the subtraction we've added around dependency injection around classes around Objects around interfaces gives us the ability if we want to take it to define what actually is an API in Ways that allow us to evolve the system without breaking things for contrib developers every time we sneeze So if our old pledge was essentially we won't break modules in minor versions, which was our old promise The new backward compatibility policy for Drupal 8 reads more like this We won't break well-behaved modules in minor versions For some definition of well-behaved We need to define what well-behaved means in order to allow ourselves to evolve So what makes something well-behaved a well-behaved module is one that uses parts of the code that we say as Core developers say is safe. These are parts of the code that you are supposed to be using and These are parts of the architecture and how it's put together that you're supposed to be using There will also be large parts of the code base that as a module developer You are not supposed to touch directly and if you do and then something breaks. It's your own fault Which means we need to make sure that there's enough documentation around which of those is which and A clear distinction of okay We have enough that we're saying is safe that we're going to guarantee we're not going to break that module developers Can actually do what they need to do without relying on internal data structures over here or whatever And I would argue we need to use that documentation Problem as a way to drive that separation we can use the hey We need to document what is an API and what isn't as a way for us working on the core team to say alright We need to add something here that We can say is not going to change so this other piece can change because we know this piece We probably will want to change a year and a half from now, but by providing that extra layer there We can very clearly say for contrib developers. Here's what you're supposed to use. This is the part. We're going to promise you Surprise surprise for me. I recommend we look elsewhere for ideas in particular Symphony has a new backward compatibility policy that they developed with our input which is great and They've got a link here these slides will be up if you just Google for symphony BC policy It should be the first thing comes up if you want to play along at home Basically comes down to tagging classes and interfaces and so forth with more Documentation tags that have very specific meaning about how stable something is so Interf is over simplified Description of what they have interfaces if it's tagged API then you as a consumer of that someone using it You can use that as a type hints you can use it as you can implement classes using it And you can extend that interface with your own interfaces and be pretty confident It's not going to break on you in the next version You can be very confident in that, you know, we're not going to change those out from under you If it's not tagged if it's a tagged internal and you use it and it disappears in the next version Well, we told you so And if it's not tagged at all then you can it's safe to use an implement But not to extend actually may have the implement one wrong there now that I think about it But I made three different levels of The guarantee around this won't change on you for classes And it works essentially the same way something tagged API You can do pretty much any with anything with the class is done aside from adding private methods and Properties you're probably going to rely on that code never changing Again, if it's marked internal and you use it and it goes away we told you so and Otherwise Some things are safe, but not everything again The symphony documentation has a very long list of the exact things you're allowed to do to a class When it's tagged one of these things we do not necessarily need to follow that exactly I think it's a good starting point We may want to tweak it and have something slightly different than symphony in this regard. That's okay It's just a very good place to start And on classes they do say methods can be tagged separately This I think is really important because there's a lot of places where I think we'll want to keep you know make a class Safe, but keep its constructor Private so that we can still add services to it without breaking something else and we can discuss some use cases for that Their documentation does not address traits at all, but since Drupal 8 is going to have traits in it. I would say when I say class Assume I mean class or traits So then this is essentially what our new pledge for model developers for Drupal 8 should be We won't break things that are tagged API and For normal stuff if we're going to change it It will be noted in release notes and it should be a minor change So upgrading for that should be a really easy task. We'll make it as easy as possible You may have a little bit of work, but not a great deal So think we'd like you know Like views occasionally will add something you need to make a slight tweak to it and contribute that we're already used to that Cork can do the same All right, so what are we going to tag as our stable supported guaranteed API? This is not an easy question. I Have guidelines that I want to recommend But these are not some people are getting it these are not hard rules So at a strategic level We have a policy right now that Security fixes will trump anything if the only way to fix a security hole is to break an API We break an API in the name of security. That's already the policy I think we just keep on doing that. It's a good policy. Let's you know stay with that I've got recommendations here, but this is going to require a case-by-case thought there is no you know define a rule once and then Deploy pattern applying minions to the core to apply We have to actually think this through in different places and make good educated decisions And that's a good thing It forces us to reason about our code and how we want it used rather than just blindly applying some rule. I Think this is actually a responsibility of the subsystem maintainers primarily They know their systems better than Random core people This is their responsibility as a subsystem maintainer, which also means we should in most cases defer to subsystem maintainers not always but You know if they're responsible for this part of the code base they are responsible for what part of this code base is the API in which isn't So, you know, this is a conversation. We will need to have with all the subsystem maintainers over time And as probably the strongest proponent and Drupal of never ever using the private keyword I'm going to say we might want to start using it for things you mark as API Because that is an extra level of this is not part of the API API for something that is you know extending is That's still an API So I am going to be flexible on this point. So which part of that? Correct. So for the recording if you have if you have a class that is tagged API and has protected stuff on it we are saying therefore that Those protected properties and protected methods are part of the API of that class for its child classes If you want to exclude something from that API for child classes You can make it private There's actually another way of approaching this. I've seen which is Tagging methods as API or not. That's actually something at Fabian No, no, it was not Fabian who proposed that originally, I think but there's a lot of discussion around you know protects versus private and one of the key points there that I've seen is something being public or Protected as in the language is not the same thing as being part of the API in scare quotes so Just you know should we should not assume that's public means public API and protected means Child class API we should think beyond that and maybe even just tag things as in this class These three protected methods are part of the API for child classes and these three are not but they're still protected for some other reason so again this goes back to We need to think these things through case by case and make well-informed decisions Also, just because we tagged something internal doesn't mean that we are going to be free to change it at any time Internal says as a module developer. You should not rely on this thing Not a promise that we're going to change it if we can add some new feature or improve something Without changing an internal class that's still better than breaking it if we don't have value to but we reserve the right to change This if necessary Some general rules Again, all of these are open to discussion. I would argue we should always treat our database schema as internal This is a big change from previous versions where Yeah, no hook schema altar if you write direct queries against the an SQL table that is not your own You are doing it wrong. I I've said this before a couple times in triple eight I spent a lot of time in Drupal 7 building up this great new database API and in Drupal 8 I'm going to tell you not to use it Because we have much more robust API's on top of it that will let you you know build a module that will work on SQL Mongo Redis whatever You know transparently if you have a reason to use your own table For something then that's your table fine You know if that's your API, but any tables created by core should be treated as internal and not something Contrib developers can rely on the schema for Yeah Well, that's views makes that a lot easier to say actually as does EFQ tests Don't even bother tagging them test classes themselves are internal always the test base classes Are like any other class because changing those would break a whole lot of tests But an actual test for something is not part of the API, which means all those people working to get rid of simple tests and move over to PHP units or to be hat keep going please you can still do that in triple eight You know of all of the actual test classes in Drupal 8 we can replace without it being an API break There's really no reason contrib developers should be relying on those in the first place So keep on working on that. You know never stop, please Um controllers This one I I'm a big contentious on myself in practice a well-written controller is just glue code There's nothing in there in that's interesting if there is it should be factored out to a service Which means we can get away with saying our controllers are always going to be internal So contrib developers should not rely on the individual controllers of some core module Not changing on them again, they're unlikely to change, but we're not going to promise that they won't However a lot of this means we've got all these YAML files and in many cases the structure of that file is the API What happens behind it is not This is your entry point to the system is set up a YAML file in a certain way That's the part. That's the API not the actual PHP code I would I would say As some general guidelines here, we have a lot of services in the container that are Tagged services so to find some service give out a certain tag in the container and magic happens and it gets wired into the system The interface that you have to implement for those services and the name of the the tag in the container Those are both APIs That's the only part. That's an API However The class that we will inject all those into that's internal again The API is I provide this class and I tag it this way. What happens after that is not part of the API guarantee So I'm going to talk about breadcrumbs as a good example of this later on If we have classes that we intend to be extended a lot of these base classes like Entity or controller base and so forth We're providing those as something you are supposed to extend that means that is an API And those are the classes where we probably want to lock it down tight with private variables Or our private properties However, a lot of those base classes we should break into traits some of this is already happening it needs to happen faster because Some things on those base classes we want to be public API Some we want to be private. It's a lot easier to differentiate if they're broken out into separate traits And then some of those traits can be internal and some of them can be public or API It also forces us to think through how we want developers to interact with our system Not how we think they might how we want developers to think through our system, which means treating module developers as Users of our code and applying the same you know user experience concepts to developers as we do to end users in the browser for plugins Most of the time I would say whatever the interface is For a given plugin is an API and all the manager guts should be internal. There will be exceptions to that But we want to define small surface areas Good small surface areas, but small surface areas that helps keep code loosely coupled gives us more flexibility And communicates the module developers. Hey, this is the right quote-unquote way of doing things For things in the container we should go through and mark most of them private in The symphony dependency injection container you can tag a service as private Which means you can't access it from container get you can still inject it as a dependency to some other Service that's fine, but you can't access it at random This again says things that we you're not supposed to be dealing with directly You can make private for example Route enhancers those are just an internal part in of the routing system internal implementation detail I'll say now there is absolutely no good reason for a contrib developer developer to pull out a route enhancer from a Controller or from a form you don't want to be using those services inside Controller or a form if you're doing that either you're doing something stupid or we did something stupid because you can't do something Without doing that so someone did something stupid if that's going on If we see that we can fix it by doing something not stupid instead, but we need to give ourselves this trigger Any public services we have however must have an interface no exceptions Having an interface gives people the flexibility to swap something out without playing games with extending classes The names of the services that we don't make private those are part of the API So the router we may change stuff inside the router, but the service name router that is not going to change We can promise that The entity manager whatever it's the name in this container is I think it's entity manager at this point or whatever that is That name is not going to change the guts of the code that come back of the class that comes back that can change the Tag itself will not I would actually You cannot put you know at API into a YAML file I'm just saying we should document as part of our overall documentation strategy if you have a Service in your in the container that is not marked private then that name of a service cannot change for the life cycle of Trueblades we may add more, but the name of that service will not change so Outcome of this conversation should be we go write some kind of API Definition documents based on this and discussion which will include that statement assuming people don't throw tomatoes at me for that for those YAML files I said the tags we put on Services that's part of an API the keys in routing YAML files that's part of an API The code that's triggered by it however is not So as an example in the routing system right now you can specify a lot of Magic keys that do various things so you can say underscore form here's a class So that's a form that we're going to show at this page great Entity view whatever the entity is in the parameter show the view version a full view version of that entity at this page great That is the API The fact that we have two layers of wrapping objects that process this to make it work That is not part of the API the API is you put underscore form in your routing YAML file and a form shows up How it shows up is not part of the API The code behind these is not API because it's the behavior not the code that module developers are going to be relying on Config API I Would say in most cases We treat or we can treat the The keys as an API if people are going to be loading those However, sometimes we'll have some kind of wrapper around them. So we don't want to contribute developers Accessing some other modules config objects directly this one Honestly, I don't know I'd like input from the CMI team on it because they're gonna have a better idea here than I am again, this is proposals for conversation starting and And other random stuff We do have a lot of third-party interfaces from symphony or elsewhere Many of those are already tagged API by symphony, which means we are can be pretty safe They're not going to change on us when we upgrade to symphony 2.6 in core for example For those that are not we can consider putting an empty extension on them So some interface in symphony we'd have interface in Drupal that is the same name and just extends it and does nothing else that gives us a place to Futs with it and add some back to compatibility pieces if necessary if symphony changes something on us We don't necessarily need to do this everywhere, but it's something we can look at doing If we think we're at risk of something changing upstream I don't think the other libraries we're relying on beyond symphony have this well-defined Of an API definition, so we may want to do that more for others. I think this is when it's open to debate If we have a base class that is intended to fulfill an interface and it actually is not a Trivial implementation of the interface we probably should just fix that problem in the first place In this case. I'm looking at block base. Who's looked at block base the block interface and the block base class Have almost nothing in common So before we make block base an API, let's fix that problem We need to refactor that piece so it's stable and this is again a place where all right. What do we document? Oh? That doesn't make any sense. Let's fix that before we document it documentation can be a good architectural driver Former rays Core has lots of former rays all over the place almost all of them should be internal Because if we say we cannot touch a form array then We basically can't change anything in core. We cannot improve the UI at all so Obviously if we don't have to to break a form. Let's not but most forms we should say We are not going to guarantee that your altar hook will never ever break it probably won't but we're not going to promise it We may want to make an exception for the node form. However, I think that's debatable That's you know the most commonly altered form. I would suspect or the one that's most likely to Do weird things if it changes and there's an altar So we may have some exceptions like that, but overall all of these big arrays arrays are not an API If you rely on random naked data structure as if it were an API either you're gonna break something or you're telling someone else They can't improve things neither of these is good. So where we still have these arrays We should assume that they are not part of the API The key definitions are you know the form element number is going to be the form element number Where it is in a given form or if a given form uses a table versus You know pre and post fix or whatever that's not part of the API just the array definition itself is All right, this is a lot of abstract stuff. Let's see some of this in practice Again, these are examples of how I would recommend Documenting these particular systems. All of this is subject to debate and or tomato throwing Breadcrumbs system. We don't actually have a maintainer for right now But it's nice and small and it was mostly written at this point by two or three people one of whom is me So I'm comfortable talking about this one The breadcrumb builder interface actually who has been following how the breadcrumb system works in d8 now Okay, not most people so breadcrumbs in d8 now instead of a function you call and hope you could you get called after someone else Has called it to set a breadcrumb. We have a series of breadcrumb builder services Which will apply or not given the conditions on the page and then we have a Manager class that's when a breadcrumb block, which is an actual block now Displays it will call that service and say all right get me the breadcrumb as defined by whichever the first service is that says I care This gives us a much more deterministic way of dealing with breadcrumbs much simpler And you don't need to go gripping for who called Drupal set breadcrumb and did they do it too late for me? Just get in after them. That's a terrible thing. We actually have a breadcrumb system in Drupal 8 that doesn't suck So each of these breadcrumb builder objects, they have an interface that interface is probably part of the API We tag that that's pretty much not going to change at all The tag you use in the container you breadcrumb builder you define your service tag at that it gets wired up. You're done That's part of the API The name breadcrumb for the service which right now is registered to that's manager But you could wire a breadcrumb builder to it directly, which is awesome That's part of the API That's it the interface for that Chain of responsibility manager that will you know try each one in turn probably that's normal I doubt we're going to change it, but we might and The manager class itself you've got now that's internal if you rely on this particular implementation of wiring these together I'm not going to promise to you that this won't change as the Not the maintainer of that subsystem, but someone who probably would qualify as I'm not going to promise you that this won't change I can say these won't change, but not this one That's the kind of thought process we want to go through other people may break this down differently But this is the exercise we want to go through Breadcrumb builder base gets rid of it. I think we could just eliminate this class entirely all it is right now is a wrapper around two traits with the translation traits and Link trait as soon as we create it, but hasn't been created yet once we factor The link generator Utility methods out to a trait this entire class will just be using two traits at that point It's no longer useful people can use a trait in their builder class directly and then they understand what's going on a lot better So in this case thanks to traits we can just eliminate this entirely and that solves the question of whether it's an API or not I think that's a good thing Like it's something a bit more complex here again, this is open to debate I would say this is the API of The routing system Route filters route enhancers and the fragment interface these are both from symphony cmf not from Drupal So we may want to have our own local interfaces that wrap it that are just they are extending it. That's fine The and then some of our utility base classes all exceptions and the object that Contains the results of a block or of your controller Some of these other interfaces that you're probably never going to implement yourself But you're going to use as a service so URL generator So stuff like that control resolver interface pretty much. No one is going to use this one in practice It's all internal, but I'm being generous here since that comes from symphony originally Route builder and route provider Unless you're writing an alternate back-end for the routing system say for MongoDB or Redis or whatever Which actually yesterday someone showed me a prototype of the routing system using Redis as a back-end, which I think is seriously cool You know, there's maybe five modules that will actually Care about those most module developers won't even know they exist. That's fine These don't need to be part of the stuff rock solid API if we ever do need to change something on these There's five modules that will care and we can just communicate to them And then again these only really useful for a Small number of people to actually want to ever change so they don't need to be part of the fully public API and Pretty much everything else is internal There's a lot of I went through the routing system There's actually a lot of classes in there most of which model developers should not ever care about Most of that directory is an implementation detail So all this dumping stuff you're never going to touch that The URL matter you're not going to touch that the route provider Implementation we have right now. You're not going to touch that All this stuff about rock compiling. No the filters and enhancers the interface is the API The particular classes we have in core that accomplish the stuff they're accomplishing now The fact that it's accomplished is the API the fact that we will you know route based on the The a method of an HTTP request and that will return the correct error message if That they can't match. That's the API the fact that we use a route filter for that is not part of the API The existence of route filters is the API, but not the specific classes. We have so I would tag all of these as Internal so if all of this stuff is internal. What is the API of the routing system? It's not a small amount of code What is the API of it? In this case, this is the API The 98% use case for interacting with the routing system is the routing yaml file for the vast majority of model developers That's the extent of the API you actually care about. That's the part we promise The fact that there is a underscore title Property or a title callback property. That's API the contents and controller Methods, that's API the fact that if you specify content We set a controller and wrap it and it's of this particular class that we wrap it with not part of the API don't rely on that Same thing with form The API is if you specify underscore form and a class name you get a that form at that URL That's it details of what happens behind the scenes to make that happen are not your problem The fact that we can route based on format and method the entity Keys for all of those things. That's API You know permission for doing access check this way What happens behind the scenes to make the permission check happen is irrelevant But we won't change the fact that underscore permission means you need to have this permission We may expand this to say oh you can say access content overview plus whatever so you need to have two permissions But your existing code Is fine and if we can't It add that functionality without breaking that horribly we won't have that functionality and we need to accept that as core developers Hey, there's things we won't be able to do And when we find things that we want to do but can't there are ways to work around that For example If you want to extend a class or rename it We can do something like this We've got a class called book manager right now in the book module fine. Let's say that's tagged API or maybe internal So we can in core at some point in 8.1 or 8.2 extend it and create a new one Which it's been argued that should be called book repository in the first place. So let's use that name and Then stuff in core that we can control can start relying on the new one and do whatever the new stuff is Anything can trip it's still relying on this one But this move class matches all the same Interfaces and type checks So it can still type check the old one and still do what it's going to do and it's not going to break This is okay And at this point I would say probably book repository should not be marked API maybe internal Maybe normal debatable case by case But this gives us some flexibility and builds up only a little bit of cruft With interfaces say we have you know some interface. It's tagged API. We want to do something new in a way that our rules won't let us extend the interface put new stuff on it and then our Code that is dependent on that interface Can just do a check internally and if it's the old style interface assumes some things if it's the new style interface Assume others this code in here is not part of any API anywhere But this lets us allow contrib modules to still pass in that old interface and we can deal with the old or new versions This will build up cruft in the system That's okay because we know about it and Anytime we do that anytime we add this hey, we're working around our BC pledge here Immediately file an issue assigned to Drupal 9 to sort that out That gives us maybe an extra issue tag. I don't know That gives us when we do open Drupal 9 development whenever that is in a couple of years We have a hit list of here's the cleanup. We can just go through and do immediately These are all API breaks, but it's just going to clean up a lot of that cruft Do that first blitz through that in the month or two and then we can start from whatever actual things We want to do for D9 and we've got that tracking in place and we can very easily signal What we're doing in the future? Especially if we can be thinking ahead to D9 and saying oh, we're going to want this book repository thing or this enhanced interface for D9 We know that we're going to provide that in D8 contrib modules that want to require 8.2 and later can use that new interface Which then doesn't change for D9 great. It's a much smoother transition path less work for modules to update to D9 later Because they can do it in bits and pieces as long as we are careful about it. I will give a warning however This is the very first time that Drupal has tried to do something like this And I said it's gonna require thought it's going to require Thinking things through it's gonna require planning all of which we are rather bad at because we have very inexperienced that Planning is not something Drupal is used to doing. We are going to screw this up I will say this now. We are going to screw up and find ourselves looking at a piece of code and saying Oh, I can add this function out. It'd be awesome if I just fix this one little thing, but that would be an API break Drat We should look at that as a learning experience Culturally and then do it better in D9. We are going to hurt ourselves in core by doing this and we need to Because that's how we learn how to build better more abstracted more loosely coupled APIs That will give us more freedom in the future So let's learn by failure and see what things did we get right in Drupal 8? That give us the flexibility we want and what things did we just not do right either? Architecturally in terms of documentation or whatever and let's also remember we can raise the guarantee on something We can't lower it if we have something tagged internal and later decide, you know what? This is safe to just release take that internal tag off in 8 1 or 8 2 or 8 3. That's okay Some things tag normal like all right. We're done with this one now. It's a to we know we're not gonna change this one again It we're happy with it with that up to API. You can't go the other direction Which means for right now in 8.0? Let's be very conservative Let's not tag things API just because we think someone might use it if we are confident This is the public API and we are confident. We do not need to change it ever again until Drupal 9 then we can tag an API if We think we might need to let's give ourselves a more regular room and communicate to module developers Here's what we are promising. Here's what we are not promising and Get feedback from that and we'll probably get feedback from contrib developers saying hey this thing I'm I have to use this So either give me another way or don't break it and we can then do that which is something we've not been able to do before So that's my proposal That's my recommendation of how we managed this Let's discuss and then probably have a buff or Meeting on Friday to start turning these thoughts into an actual BC policy. Thanks I'm just kind of curious Larry is do you feel particularly because we are probably gonna get this wrong at the beginning that there's benefit in having more granularity and what we What kind of tags we might use? so some examples, I'm thinking of would be something like having a API candidate tag something like that that might say well We this is something that we want you to use, but we're not necessarily saying that this is fully baked yet or fully stable yet Because tagging effectively everything is internal It then becomes harder for contrib developers to distinguish well Is this something that we don't intend you to use or just not ready yet? Maybe that's an interesting idea The challenge is we could very easily have way too many levels and it becomes too confusing but maybe if having a fourth level for probably API or Beta API that might be useful. I'm not sure yet Microphone With the API candidate tag out only suggest that we Include a link to the issue where you can discuss. Why does it candidate because knowing it's a candidate? Isn't much without the ability to I guess up vote or down vote. It's candidacy. That makes sense Discuss and discuss what might be wrong with it. Yeah, or the model that wants to implement it so I I Overall, I think that the way that you've broken down the different Put the different parts of our code base and made recommendations is very helpful But I also noticed that there is there is an enormous documentation effort here. First of all, there is an enormous like Thought process effort and you're also recommending some rearchitecture And at I need to point out much not you you promise it's not much Okay, I don't think it's a lot of rearchitecture. That was my action My first question when you started to talk about is like are we in Drupal 8 actually really really at the point where what we say? Which is that we modernized an architecture and therefore we we can make changes without breaking BC Are we really at that point? Because I think that the Drupal 8 cycle has been a learning experience for everyone who works on core And then I have a follow-up point to that question, but I Think we are certainly closer to it than we've ever been Whether we're closer enough or not, we won't know until we try and that's why I recommend Subsystem maintainers go through and look at their systems and say all right What parts of this can I now guarantee and what can't I and if you end up with boy? I can't guarantee anything. That's a problem. Let's fix that Better to know that now than a year from now. I'm hoping it's a small number But things like you know get rid of breadcrum base. That's a small thing It's I wouldn't call that a rearchitecture, but I think it is a smart thing to do That leads me to my second question, which is Are you possibly and I think the answer is yes, it's a loaded question. Are you possibly overestimating the involvement? time availability Drupal 8 awareness and Confidence of component maintainers because I have found that group of people in the course of trying to get them to do stuff To be very inconsistent in their level. There's there's there's people who are extremely active in Drupal 8 there's there's a Third or half of our components that have no maintainer at all And then there's components where the the maintainer might pop in once every three or four months to say this is a horrible idea and then go away again, so I Did the breadcrum and routing examples on the plane on the way here from Chicago? If you are paying attention to core It's not a large task to do a first cut for those components that don't have a maintainer. That's a problem we should probably find someone and We should not rely exclusively on component maintainers for this But they should be the one driving the conversation in their areas And that leads me to my point, which is that I All of this is something that we need to do and we definitely need to have a policy for a point But my recommendation and I think you sort of got this my recommendation would be that we start with the big the bare obvious minimum things like you know Controllers Renderer raise those those don't make good API so we can start by saying we will we will consider breaking those in 8.1 And and start with like the most important things for the AP level, but I am very concerned. I want to remind everyone that we are 15 issues it's actually 14 issues because Dries is just behind this week Away from a beta release candidate, which means in theory that our APIs are stable-ish enough already out for contrip At least at least the ones that we've defined as critical APIs Which includes the entity field API the plug-in system the routing system and the configuration management system in the theme layer Yeah, and I would say all right. What does it mean that when we say that the entity API is stable enough for contrip? What parts of it all 50 classes or just these eight? That's the question that we need to answer Whether we answer that you know whether answering that is a beta blocker or The point that I'm trying to make Is not that can we change more later the point that I'm trying to make is we need to stop changing crap Because right now we are over we are already over the length of the Drupal 7 release cycle now The first year was kind of a dead zone But it's still been a very long time since people had a new version of Drupal Drupal 8 is freaking amazing It is a huge advancement over Drupal 7. It is modern the code base is better. The functionality is much better and there's a serious serious risk to the Ecosystem the commercial ecosystem we all rely on if we continue to put off the delay of that release So if this is something that and when you talk about it it frightens me because it's like this is good planning that we should do but I would Like what we need need need need need to do is instead focus on in fact minimizing the the API change and and like You know bike shedding and perfecting that we do both in terms of like how we how we invest our time and in terms of the code Base itself so that we can you know decide You know this is this API is hideous, but we can live with it and we're gonna live with it So that we can get to release and yeah, I the situation is is kind of urgent I'm not gonna disagree with you at all on that point So then I guess it just serves a reminder for everyone While I think like in input on this is amazingly valuable Focus your energy energies on it at least on the API's that matter most if you're going to spend time Trying to make these decisions like think things like thinking about what in the entity system That's a great example like think about what in the entity system really really needs to be stable But at the same time don't take time away from fixing the entity system So it's ready for release because there's a lot of criticals out there and they can trip people in the room We don't really work on core This is a great time to give us feedback on what parts of this are you going to want to use as an API that we should then tag As API you know we want that feedback so we can be intelligent about this. I should probably say for the recording My name is Jess. I'm XJM. I work for Dries in the office of the CTO and my full-time job is droplet release management So that's why I'm being So first I have just a statement that have To shape some thoughts and maybe get some feedback on it So as a more of a contrib developer Some of these decisions about like what's API and what's internal Like I would never look at L the link linking function as something I would change, right? It's like don't hack core like obviously but now you know what you're presenting is essentially saying that You know for contrib developers It's going to be harder for them to understand like what's L and what's not now right since this is object oriented You can extend things and take things, you know, you're trying to set up something that says like Here's an indicator that this is something that you shouldn't change right because Like obviously L. I wouldn't never refer to it as an API, but it's a function that you use and rely on But I guess I would kind of take the parameters of L as an API so In shaping the conversation about like how do we document this? I think for people who aren't familiar necessarily like with what's going on is just saying like think about it like L Right like you we will change the inner workings of link because that's what routing is doing and like it's kind of a no-brainer that you're not gonna Unless you're like forking and hacking like working on core you're not gonna try to Extend a route enhancer and modify it So I think there can be lines that are drawn to help with the massive documentation effort to use people's existing experience with D7 to kind of on board them to that and to that example in particular, that's why I Believe I had the oral generator interface, which is where the contents of L now live. Yeah, that interface is part of the API The class we have that is the default implementation is not so we could change the class swap it out to whatever else and The interface is still not changing and that's what you as a module developer are relying relying on the the function name and the Parameters to it essentially That's the API that you can rely on The fact that oh, I'm on this particular site for whatever reason I'm going to extend the generator class do something different I'm not gonna promise you that that extending of that class is never gonna break I am gonna promise that the interface you're relying on in a module is calling the L function or calling the generate method Is not gonna break and that's the distinction we need to be able to make my other thing was just about like deprecation and having deprecated function so Like Tagging things as like Tagging it as with a D9 issue that says like we've got cruft now And we should get rid of this in D9. I was just wondering if people are thinking about well Maybe marking things as deprecated in minor point releases or even carrying that through I mean, it's a question of how large you want the code base to grow What you know, what do you really want the developer community to do with these types of? You know API changes for major versions. I was just wondering what thoughts are around deprecation So we are using at deprecated already in core mostly to indicate we haven't deleted this thing yet But we're going to before eight O releases I am completely in favor of using deprecated within the duplicate cycle say You know, here's this new interface that's going to replace the old one. It hasn't yet Here's the issue in D9 to actually delete the old one the old one is marked deprecated So contribute developers you probably want to start using the new one, but the old one is still going to work for now And if you start using the new one now great, you're already halfway to being D8 or D9 compatible Right, so I am completely in favor of using deprecated till then just to reiterate deprecation really only stands for a major version and then all deprecated functions will be removed in the next major Release for anything that is API or normal. I would say yes You deprecate something we don't actually delete it until until D9 Thank you I had two quick thoughts one was going off of Jess's point about you know, I think this is a great idea I love the the concept of it as a developer as a as a contribute maintainer especially It's like knowing what I can use safely But if it's something that's too big or that we're really concerned is going to push out D8 I agree that we're sort of we're already Kind of a feeling I got from Jesus keynote was like next year's the experience web using his term And next year is the first time that D8 will hopefully get out and that's the end of the assembled web By his own keynote were sort of lagging a little bit there And so I I would agree with the concern that that may be pushing it beyond that So maybe something to think about if it's not pushing this too far is is this an 8.1 feature itself? I would say no because if we do none of this until then then people trying to build modules on 8.0 have six months of oh However No, we stopped we stopped breaking things for core releases in the past Well then so taking that further recording the suggestion is you know six months of contrib developers having feedback for what should be the stable API Fine, but then that means you're taking those logs to conclusion 8.0 doesn't have any API guarantees on it all so who's gonna be done enough to develop for that I think we need to do some of this before 8.0 and And It should not hold up the release by any significant amount Microphone microphone. He's saying whatever it was generate the default node page That's it So I mean but potentially So I think to just this point earlier. I'm not suggesting we refactor five different systems entirely just for putting tags on it That's not what I'm suggesting. I'm I Would kill me I'm suggesting things like oh How would we document breadcrumb base? Oh, we don't actually need it. So that's a very simple change to make I'm expecting more things like that. That's one issue to fix in core. That's not a big deal Any kind of refactoring we do just for this documentation purposes is at that level as far as I'm concerned not at the oh Let's change these 12 classes if we have to change these 12 classes for something We've already screwed up and we're just in damage control mode. And yeah, that should not block a release So the second thing that is sort of a thought or request is if we do get to the point where we have core Really nicely tagged like this and we can actually do some analysis on the trip modules Is it be a fantastic service? I don't know if it's something we want and contribute self maybe something encoder But I think even better it'd be something on D2O itself that says two module maintainers. Hey new core release By the way, you're not using three deprecated classes Yes, please so some sort of method or system that tells you you're using six unsafe and three deprecates You should seriously look at updating your thing to work with the latest release So anyone who wants to work on that once this is in place. I would love that. I love this idea. So just thought for everyone Just a thought that bounces off of that You know as as somebody is looking for a place to contribute it would be nice to go through as As many of us do at nights on Friday night We just obsessively look look through all the different modules that are available Just to see to find something new. I know you all do that I do that so that stop describing my life We're twins So that you could find which modules have work to do and so you can jump in their issue queue and just oh I can fix that I'm good with fixing that you could be like a road warrior that way, but I am I'm just basically wanted to say I'm happy. I love your talk somewhat disappointed because I thought the talk was going to be about What are we doing right now in the issue queues in order to get things ready for? The eight-point release that we can shove to eight point one Because it seems like we there has been no conversation About what is eight point one? What are we what's out there in the issue queues? That's unresolved right now that can be pushed safely to eight one. There has been some discussion of that It's not all that formal at the moment But yes there that is a whole conversation unto itself that I'd be interested in having to Is it is it off topic for your talk? Can I respond to it? Let's leave go first and then you can jump to it. Okay, I Wanted to ask if if parts of this can be reframed For Contribs run responsibility or for individual sites responsibility. We already have some soft conventions around how Individual sites keep track of the things they hack with either patches dot txt or just keeping the patch files around like people already Hack core and modules in ways. They're not supposed to that's part of the normal site building process Unfortunately, so I think we can extend those concepts here. We could have the way of automatically tracking how many modules Extended given class these problems are getting more knowable when all we have is Hook something alter. It is difficult to know What is being altered? It's a lot easier to rep all of contrib for extends entity base we could have a good citizen module tag and perhaps an application process for Domain access is a good citizen module. Please please run its tests. Please run its tests When core patches are made because if it breaks a good citizen Module, we don't want that patch Or that patch needs to look at the failing tests in the good citizen modules. I mean, I'm just Yeah, but but there are ways that some of this responsibility can be shifted So it's not just hey core. Hey already overbooked core maintainers You have a new problem in a sense. This is contribs problem. You could say everything is internal Until you until you contribe or you individual sites. Tell us that you need this to be public. I Think that we should I like the idea of the feedback from contribe. I think we still need to have a minimal api Tags set for 8.0 just to give contribe something to work with sure, but I agree. Let's keep that small if we're not sure Leave it normal, which is the probably won't change But we're not gonna you know across our heart hope to die on it and and if you are writing a Contrib module or a site specific module and you want to extend something That's not tagged as api file an issue if you don't you're doing the equivalent of Hacking a module and not filing a patch to d.o Which people do people yeah people patch their modules and don't post those patches to d.o And that's that is a that is how kittens die and And you're shooting your you're shooting your future self in the foot when you do that You are shooting your future self in the foot now if you extend a class It is not tagged as api and you don't tell anyone people will do it people will extend classes and not tell anyone But they are shooting them their future selves in the foot when they do it because their site will break when that class changes Yeah, so yeah, definitely the ability to gather more data and more automation around this is definitely a win I think we have time for one more and then we'll go to lunch So before you talk Who's interested in having a meeting on Friday at the sprint about this topic to start drawing up some guidelines? all right So Friday at the sprints will set up a table or something and start drawing together some recommendations that we can post And if you're not gonna be a part of that still come to the sprints on Friday because we've got a release to get out to agnab it And last comment. I really like the idea of the feature release I think this is the way to go and so we don't have to wait for the full Release cycle for a triple line to be out, but there are like so many contra modules out there in triple I love the work all the maintainers are doing. Do you expect the full support from all the maintainers that if something is Release in 8.1 or 8.2. Do you expect them to go back to their module? Look at what they are using and what has been changed so they can be changed Some yes some no that's why we need to get this communication out and then restrict ourselves and not break things On contrived if we can possibly avoid it Which means core developers are gonna have some pain dealing with hey I actually have to support something for a change and it's about time the core team felt that pain I Say this has a member of the core team If somebody is going to release some security patch or something in their Components how would that fall in our release cycle would that be a feature release or security release for triple The odds of a symphony security release at this point Breaking an API are extremely slim So I would roll those into our security releases and I know our security team and their security team are in contact I don't know details of it since I'm not on either security team But some coordination around that so you know they release a security release We get that with security release out ourselves immediately would be a good thing So there is conversation happening around that So since it isn't really in topic for Larry's talk to Chris's question about What we the kinds of things that we do put in 8.1 8.2 8.3 as opposed to just what kinds of changes will make And and how we manage that process in the issue queue That's that's something that we're starting to explore We've just started doing more of now as we get close to beta So if you're interested in talking about that you can come talk to me We can have a little mini buff if you want I have booth duty at the aquia booth from noon to two today So like right after this and you're welcome to come by There's like even a seating area where we can hang out and talk about stuff and we have a whiteboard So if there's anyone here interested in that please please stop by and I would love to talk about it more And if you look at the slides from my prog talk I had lists there of just long list of things that I felt were totally legit to add an 8.1 I've already got a long list myself of things. I want to add an 8.1. That's just I felt that was off topic for today This is just a small question, I guess, but I wanted to get it since you're in the room Jess Is there a reason why we can't tag certain things now as API candidate kind of things and actually get that discussion From contrib maintainers now Rather than waiting for an 8.0 release and then having that kind of six months really discussion before 8.1 The trade-off there is just in terms of resourcing for core developers I think that is actually a great idea and I think that the beta would be a time to at like beta one to our C one would Be a time to start having that conversation with contrib developers because that the beta is that is for them, right? But the trade-off of course is just in terms of the the actual work It takes to to do those things and and whether or not that time could be otherwise spent And I think it it also but on the other hand it could be a great opportunity to get actually get contrib developers Looking at the core code base and saying like these five things are a PA. Are they sufficient? And that gives that also a branching off point for them to get involved and help resolve those critical So that actually is probably a good idea I just don't want to make it a requirement for the release or or like I an expectation for the release I think that it's an opportunity and that that's another place where I really think we need to Get subsystem maintainers driving a lot of this conversation because they have the one little piece that they can focus on for that Now there are people who are subsystem maintainers for eight different subsystems, but that's a separate problem that already exists It's not a new problem, but you know having the queue system It has a maintainer on it who doesn't maintain anything else let him drive the conversation for that piece It's a nice small conversation and We're done that helps break things up further. We need more subsystem Yes, please you're looking for a way to contribute to core and you have time and passion You will stick with it also come talk to me right after this in the exhibition hall. Yes, please We're over time. Let's go have lunch Yes, and please do follow me on Twitter follow Palantir on Twitter center for our mailing list all that kind of fun stuff and so forth