The addition of a /libraries folder (like /modules and /themes) for the purpose of contrib. and project specific custom modules to place shareable javascript or css libraries that should not be included in a module or theme repos due to licensing restrictions and policies of Drupal; is necessary.

In light of 3rd party libraries and content on Drupal.org module and theme developers need a location to instruct Site Builders to download and install said library to.

README should contain:

  • why this is folder is here
  • notes/links on use of *.libraries.yml file in module/theme to access said library.
  • For modules: and installation process points with hook_install (*.install file) and use of hook_requirements($phase) to check the 'install' phase -- demo code
  • extended use with Libraries API 3.x -- hook_library_info()
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Dave Reid’s picture

Issue tags: +Libraries

Adding 'libraries' tag.

stri_berry’s picture

My normal installation routine before installing drupal 6 was to create
sites/all/modules
sites/all/themes
sites/all/libraries

I see in drupal 7 alpha (6 I think) that you've added 2 of these folders, which is fantastic.
sites/all/modules
sites/all/themes

So I second this suggestion, please also add
sites/all/libraries

greggles’s picture

Seems reasonable to me. What do we need, a README.txt to commit into that directory?

Dave Reid’s picture

Yep that should be it. Anyone feel like drafting a basic README.txt now?

travelertt’s picture

FileSize
196 bytes

Here is a first draft of the README.txt file that could be put into the sites/all/libraries folder.

Please get sites/all/libraries into core, it's a pain to always have to add that little folder into every installation when it is used so universally. Hey, it couldn't hurt.

jbrown’s picture

Version: 7.x-dev » 8.x-dev
Status: Active » Needs work

We don't use // $Id$ anymore.

travelertt’s picture

FileSize
185 bytes

OK, Line 1 is removed.

travelertt’s picture

Status: Needs work » Needs review
Tor Arne Thune’s picture

Looks good to me. I too create sites/all/libraries every time, so this definitely gets my support. Can't see any downsides.

lyricnz’s picture

Does core have any support for sites/all/libraries? No. hook_library() *could* use that directory, but doesn't.

This directory is a feature of a contributed module (libraries) - so I don't think core should be creating this directory.

Unless... Libraries module is included in core, which I would totally support :)

aspilicious’s picture

Title: Add an 'empty' sites/all/libraries folder to encourage people to use it properly » Add the librairies api to core.
Status: Needs review » Active

Lyricnz is right... Changing title...

I couldn't find any issue dealing with this. Currently contrib does whatevar it wants with external libraries. In D7 we have hook_library but that is not enough.

- Contrib uses the libraries api
- Contrib doesn't use the api but places the files in the libraries folder
- Contrib just put the library in the module. (mostly it also includes ancient jquery files and stuff)

I think it's a good idea to bring libraries api to core (or a subset of it) so people can use a standard way to handle these external dependencies.

EDIT:
If this is not going to happen we can discuss the original issue.

sun’s picture

Title: Add the librairies api to core. » Add Libraries API to core
Category: task » feature

Not sure whether this makes sense. Note that Libraries API supports libraries folders in

- sites/all/libraries, sites/default/libraries, sites/<site>/libraries
- profiles/<profile>/libraries (for installation profiles)
- /libraries (for distributions)

As far as the actual Libraries API functionality is concerned, I'm rather opposed to it - there are still too many unknown and unresolved aspects. The only reason "it works" right now is that we "just hope" no one is running into the multidimensional problems.

Note: Please keep core's built-in hook_library() support out of this discussion. It's totally different.

Anonymous’s picture

Please shorten it to lib instead of libraries.

DamienMcKenna’s picture

ivanjaros: The full "libraries" word matches the use of the full words "modules" and "themes", so shouldn't be changed.

I think rather than just saying "add the module" how about defining a set of functionality, which the current module may or may not already include, and we add that step by step?

RobLoach’s picture

Libraries API is meant to be version agnostic. Drupal Core depends on a specific version of a given library to be there, so like sun said, I'm not sure this is the direction we want to go.

Please shorten it to lib instead of libraries.

Let's move that discussion over to #1431804: Bikeshed 'lib' vs. 'libraries' directory.

kenorb’s picture

klonos’s picture

Version: 8.x-dev » 9.x-dev

...I guess this is D9 material now :/

cweagans’s picture

Title: Add Libraries API to core » Add an 'empty' libraries folder and encourage people to use it properly
Version: 9.x-dev » 8.x-dev
Status: Active » Needs review
FileSize
322 bytes

I'm not so sure about that. I agree with sun that the libraries api might need a bit more time to mature in contrib, but the original proposal (to just add a directory and a readme) is still totally on the table. Whether or not core has direct support for it (where support is checking to make sure that a library is present, that it's the correct version, etc) is not, in my mind, a question that matters. IMO, anything more advanced than encouraging people to use this directory belongs in contrib for now, but we can certainly lay the groundwork for Libraries API in core now. Getting people to standardize on placing third party libraries in /libraries seems like a very good thing in my book.

DamienMcKenna’s picture

IIRC there are some other issues trying to decide where 3rd party code should go, this should be postponed until those issues are decided upon (no, I don't have an issue # off-hand).

tstoeckler’s picture

When the core/lib directory was introduced I strongly fought that because of the confusion between 'lib' and 'libraries'. At that time it was decided that, we don't really care and accept that. So this shouldn't be postponed. If we decide on / find a better way of asset / library management then that's good. But until then 'libraries' is the de-facto standard and we might as well help people by introducing this directory by default.

JohnAlbin’s picture

Yeah, the lib vs. libraries thing is annoying. Over in #1663622: Change directory structure for JavaScript files we're dealing with the fact that we can't have a core/libraries directory because core/lib exists already. We're moving the 3rd party, non-PHP vendor "libraries" from core/misc over to core/assets/vendor. And eventually we'll move Drupal-specific stuff from core/misc stuff into an organized structure of: core/assets/js, core/assets/css, core/assets/images, etc.

So they'll likely never be a core/libraries directory. Not sure how that affects this issue since we're talking about downloadable, non-composer PHP and JS and CSS libraries instead of composer-driven PHP libraries, etc. And while "assets" applies to the JS/CSS stuff, it doesn't apply to non-composer PHP libraries.

Pancho’s picture

Hmmm. How do we move forward? Do the Libraries API people have a battle plan?
Otherwise #18 might be a good starter, with the only real alternative to a /libraries folder being a /assets folder. The latter might be interesting because name-wise it doesn't collide with the lib folders. While this would be a change regarding what people were used to in D6 and D7, once grasped, it sounds more like a place for everything, not just full-fledged libraries. This might even be beneficial. We might want to discuss this one further.

As a new feature resp. an API addition, some full-featured or basic Libraries API can be added at a later point, even in a point release.
Note that we'd like to add system stream support for libraries in #1308152: Add stream wrappers to access extension files, but therefore need to know what to support...

mgifford’s picture

geerlingguy’s picture

So, I am setting up a new D8 site, and according to the CR Most Drupal core files now live in a "core" subdirectory, it seems the pattern I should use, following the new root directory 'modules' and 'themes' layout, is to create a 'libraries' directory in the root of the D8 project structure.

In D7, I know that I should've created a 'libraries' folder at sites/all/libraries, but it doesn't seem documented anywhere what to do in D8. Could we get some clarification, and maybe also update the change record to at least mention libraries?

mgifford’s picture

Issue summary: View changes
Status: Needs review » Reviewed & tested by the community
Issue tags: +Needs backport to 7.x

@cweagans patch addresses this issue for contrib. I really don't know why this has waited 2 years. This is the pattern that contrib users will expect in D8. This should also be backported to folks who will still be setting up D7 sites.

tstoeckler’s picture

For D7 this makes total sense, but for D8 I'm not so sure. Per #21 Libraries API will probably want to put JS and CSS in a sites/all/assets directory and for non-Composer-using people may support a sites/all/vendor or something. All that is still vaporware, though. So for D8 this issue can only reasonably be "postponed". Whereas in D7 this is totally valid, so I suggest retargeting it for now.

alexpott’s picture

Version: 8.0.x-dev » 7.x-dev
Status: Reviewed & tested by the community » Needs work
+++ b/libraries/README.txt
@@ -0,0 +1,3 @@
+(such as a PHP or Javascript library), those resources should be

PHP libraries are not going to go in here. This is what composer or composer manager is for.

I agree with @tstoeckler this issue needs more discussion for Drupal 8.

greggles’s picture

Title: Add an 'empty' libraries folder and encourage people to use it properly » [7.x only] Add an 'empty' libraries folder and encourage people to use it properly
Issue tags: -Needs backport to 7.x

Making a patch with the contents of the last README.txt from #7 by travelrtt.

Updating the title and tags to indicate that this is only about D7 and needs no commits on 8.x.

greggles’s picture

Status: Needs work » Needs review

and this.

greggles’s picture

geerlingguy’s picture

Warning: bikeshed...

Can we just remove the "This will allow you to more easily install Drupal contributed modules." line? Seems like the first sentence covers what's needed here... less is more?

mgifford’s picture

Applied this to D7 and got the following "warning: 3 lines add whitespace errors."

That's not a big deal at all, but did wonder if there's any chance that adding this to a release of D7 may mess up existing installs. The way we deal with upgrades it shouldn't be a problem, but...

DamienMcKenna’s picture

FileSize
302 bytes

I wrapped the lines at 80 chars, per the coding standards. I also removed the second sentence as it's a little redundant, per geerlingguy's comment.

geerlingguy’s picture

Status: Needs review » Reviewed & tested by the community

I like it. UX win++

tstoeckler’s picture

Awesome! The usability win gained by this is non-negligible. A lot of Drupal beginners place external libraries into sites/all/modules/libraries (vs. sites/all/libraries) by accident and this will help to alleviate that.

RTBC++

David_Rothstein’s picture

Status: Reviewed & tested by the community » Fixed
Issue tags: +7.37 release notes

Committed to 7.x - thanks!

Made some changes on commit though:

-This directory should be used to place downloaded and custom libraries which are
-used by contributed modules.
+This directory should be used to place downloaded and custom libraries (such as
+Javascript libraries) which are used by contributed or custom modules.

- Included an example (borrowed from @cweagans's earlier patch) as I don't think this would have made sense to many people without that.
- Mentioned custom modules too; it's still best practice to use sites/all/libraries for a library your custom module requires.

Note that I also fixed the whitespace errors (bad line endings) on commit.

I suspect we might want more documentation here someday (similar to what sites/all/modules and sites/all/themes have) but this looks like a very good start.

  • David_Rothstein committed 2a3cf92 on 7.x
    Issue #667058 by greggles, DamienMcKenna, cweagans, travelertt, Dave...
David_Rothstein’s picture

Title: [7.x only] Add an 'empty' libraries folder and encourage people to use it properly » Add an 'empty' libraries folder (or similar) and encourage people to use it properly
Version: 7.x-dev » 8.0.x-dev
Status: Fixed » Postponed

Actually based on #26 and #27 it sounds like this should be open for Drupal 8 still, but postponed.

TwoD’s picture

Nice, but s/Javascript/JavaScript/, please? ;)

David_Rothstein’s picture

Oops, good catch. Went ahead and fixed that now via a direct commit (and gave you credit). Didn't think it was worth uploading a patch or creating a followup issue for a tiny change like that :)

  • David_Rothstein committed 49908ed on 7.x
    Issue #667058 followup by TwoD: Fix "JavaScript" typo in sites/all/...
mbrett5062’s picture

I see no reason for this to be postponed anymore. If it is in 7.x then it would be a pita for it to disappear in 8.0.x

The libraries module can easily add /libraries as a search path, and it would help with consistency moving forward from 7.x

mgifford’s picture

Status: Postponed » Needs work
darol100’s picture

Status: Needs work » Needs review
FileSize
662 bytes

I thought this was committed already and I just notice it is not. Here is a patch, which contain same README.txt from D7.

mgifford’s picture

Status: Needs review » Reviewed & tested by the community

Looks good to me. This shouldn't cause a problem for upgrades.

tstoeckler’s picture

See #26 for why I don't think this makes sense for D8. I think we should just mark this fixed.

darol100’s picture

@tstoeckler, This question was ask in the libraries api issue queue (#2511300: drupal 8 libraries location), and the response was pointing to a Drupal Answer where it said that the new libraries folder is at /libraries. In addition, there are contrib projects (like https://www.drupal.org/project/codesnippet) that already are using the libraries directory as central place to added external libraries.

This been said, I think this patch still applies.

catch’s picture

Status: Reviewed & tested by the community » Needs work
Issue tags: +Needs issue summary update

This needs an issue summary update. The folder doesn't make any sense unless you have a module that uses it, in which case the module tells you where to put things anyway. Just having the folder by itself seems like it could be confusing.

lpalgarvio’s picture

Version: 8.0.x-dev » 8.1.x-dev
SKAUGHT’s picture

Priority: Normal » Critical
SKAUGHT’s picture

geerlingguy’s picture

Priority: Critical » Normal

Please see the following w/r/t issue statuses:

Critical is reserved for bugs and tasks which are extremely urgent/break things; feature requests can go to a maximum of 'Major', but I think this is still a 'Normal' as it's not really impeding any development, more of a nice to have.

SKAUGHT’s picture

Status: Needs work » Reviewed & tested by the community

sorry, i break protocols from time to time. nonetheless, this is a critial issue. we (the community) need a spot for this.

otherwise, i'm not sure why this is so stalled. this patch applies fine. lets get this in!

SKAUGHT’s picture

Issue tags: +8.1.x-dev
SKAUGHT’s picture

SKAUGHT’s picture

andypost’s picture

Summary still needs update and probably change record needed, cos a lot of deploy scripts will be affected by existing folder

SKAUGHT’s picture

Title: Add an 'empty' libraries folder (or similar) and encourage people to use it properly » Add an 'empty' libraries folder to DRUPAL_ROOT
Issue summary: View changes
SKAUGHT’s picture

Issue tags: +Needs change record

@andypost
I've updated summary as best I understand to do. cheers. tagging for change record

catch’s picture

Status: Reviewed & tested by the community » Needs work

That still doesn't explain why we'd add this to core when only a subset of contrib modules use it, and those contrib modules currently include instructions on creating the folder. Also #26 hasn't been answered.

darol100’s picture

@catch

I have answer question #26. See #47.

@tstoeckler, This question was ask in the libraries api issue queue #2511300, and the response was pointing to a Drupal Answer where it said that the new libraries folder is at /libraries. In addition, there are contrib projects (like https://www.drupal.org/project/codesnippet) that already are using the libraries directory as a central place to added external libraries.

The only reason we should create the /libraries folder is to encourage users to use a central place to add their libraries so they can be reused for other modules if is need it. Instead of shipping libraries inside of the modules.

Here is a list of other modules that use /libraries folder.

SKAUGHT’s picture

Issue summary: View changes
Issue tags: +Reviewed & tested by the community

@catch
Please, if you take a look at the 'related and referenced by' sidebar you can see The Why.

Drupal policy 3rd party libraries and content on Drupal.org. Projects are breaking this (sorry, at least bending) this policy. Having the folder (and it's README) is the first step for subsequent drupal.org documentation to be created.

Specifically in lue of #2605130: Missing best practices for handling external libraries in Drupal 8 -- we need to establish this practice. General consensus is to use /libraries.

It is because the community has already started doing this. in addtion to darol100's list many other modules that are doing this. And yes, others still instructing people to make a 'sites/all/libraries' --> because D7 has this folder and encourages use. Core needs to clarify this for D8.

The Libraries API should certainly be core in order to provide clear practice for module and theme developers to meet policies about including libraries, and to make those libraries sharable. I certainly hope 8.2 will include it, in the meantime we need to establish and encourage this general practice. This is why core needs this folder.

WHY: because i am a module developer who is trying to port a module for D8 and there's a big black whole about this folder. As such, i agree with the placement of these libraries in DRUPAL_ROOT/libraries.

SKAUGHT’s picture

Status: Needs work » Reviewed & tested by the community
Issue tags: -Reviewed & tested by the community
SKAUGHT’s picture

(hopefully my last follow up)
libraries API 8.x-3.x README.txt ln 21 has conformed to DRUPAL_ROOT/libraries

tstoeckler’s picture

Re #64: That is just because 8.x-3.x was branched from 7.x-2.x and the README was never updated.

#21 and #26 still stands, so this is still either won't fix or postponed from my point of view.

star-szr’s picture

Status: Reviewed & tested by the community » Postponed

To me this is badly in need of an issue summary stating why this change is "needed" and why it's a contrib blocker. It's also not accurately titled because it's adding a README.txt, not an empty folder (not possible with git anyway). These may seem like small details but for an issue to be considered for commit they are very important.

Without that information my opinion is it feels off to add this to core if no code in core is reading from it and it's not something with an RFC/standard outside of Drupal like robots.txt, .htaccess, etc.

I would also say that if we truly want this to be helpful we need to include more details in the README. Unless I'm mistaken each library should be in its own folder, at least that seemed to be the convention when working with D7 modules that leveraged the Libraries API module.

The fact that on top of everything else the primary maintainer of the Libraries API module is against this makes it pretty clear cut to me, this is not ready to go in.

darol100’s picture

Should this issue #2605130: Best practices for handling external libraries in Drupal 8/9 and 10 be part of the Libraries API instead of Drupal Core then ? If standards of external libraries is going to be define by the Libraries API.

David_Rothstein’s picture

Title: Add an 'empty' libraries folder to DRUPAL_ROOT » Add a libraries folder with a README.txt in it to DRUPAL_ROOT

I think the quotes around "empty" were meant to indicate that it's not literally an empty folder, but this should make it more clear :)

David_Rothstein’s picture

Also if this is postponed we should be clear which issue it's postponed on - is it #2605130: Best practices for handling external libraries in Drupal 8/9 and 10? (Originally I think it was postponed more generally because Drupal 8 wasn't released yet and the folder organization was still in flux, but that's no longer the case.)

I don't see this issue as being specifically related to Libraries API by the way. This is more like: You decide to download a JavaScript library for your site, either for custom usage or because a module told you to... now where in the codebase do you put that JavaScript? There should be some standard answer core can provide here.

I think one reason I committed it to Drupal 7 with a rather sparse README.txt (despite also thinking that could stand to be expanded; see #36) was to avoid being overly prescriptive; the best practices here aren't 100% set it stone, so the idea was for core to recommend something and nudge people towards it, but not to get too much in the way if a contrib module wanted to recommend something different...

David_Rothstein’s picture

That still doesn't explain why we'd add this to core when only a subset of contrib modules use it, and those contrib modules currently include instructions on creating the folder.

I think @tstoeckler’s comment in #35 is one good reason.

SKAUGHT’s picture

Status: Postponed » Needs work

@tstoeckler

  • #64 is the current correct path recommend and used my Libraries API 3.x. the 2.x branch clear says /sites/all/libraries -- this document has been correctly updated.
  • #21 should be an other against core to clean up the use of the /core/misc folder (yes, core should get itself cleanup thereby)
  • #26 the libraries API (and general use by module developers) has already made the /libraries the base. without the need to divided between whether of not the package is JS or CSS -- as the package could have both... Regardless, the module defining the hook_library_info() would hold that description and links in whatever files if uses.

@Cottser

The fact that on top of everything else the primary maintainer of the Libraries API module is against this makes it pretty clear cut to me, this is not ready to go in.

sorry, what. clearly this is where the libraries API, and module developers, is at now. The posts from more than a year ago in this thread shouldn't be a reason to delay.

for sure, not postponing this issue.

@David_Rothstein

  • #35 -- again, too old a comment. steams from D7 Libraries API (and 2.x structure) as the standard.
  • i'll put some more thought into the README contents. certainly mentioning to use the Libraries API and to follow guidelines within it would be best todo (*until libraries is in core).

I've been poking through the d7 repo and was looking some more at /core/misc folder, and have come across the fact that some cleanup has occurred Change directory structure for JavaScript files. As i was about to add an issue to cleanup misc folder. Without surprise, others have been cleaning up -- a general best practice is needed to be established. even though this was 'voted' on, its not clear why /assets/vendor was chosen (nested folders). I can only see the we have a strange separation due to Composer, but then Core should simplify it to /libraries as its own best practice (ie: /module and /core/module are still just Modules.)

star-szr’s picture

@SKAUGHT - what I was saying is that from my perspective @tstoeckler (Libraries API module maintainer) in #65 has confirmed that those "old" comments are still applicable today, albeit perhaps indirectly. Perhaps @tstoeckler can restate the reason(s) from his perspective that this should be won't fix or postponed for D8 if that would help clear the air. However, based on the current state of this issue (particularly the issue summary) I'm not seeing any strong argument(s) for adding the folder. So to me any other steps at this point feel premature without a clear "why". Once we have that I think we can have a more productive discussion about this.

SKAUGHT’s picture

Issue summary: View changes

@Cottser
i've updated the summary. and will work on the content of the README and get a patch up shortly.

SKAUGHT’s picture

andypost’s picture

Version: 8.1.x-dev » 8.3.x-dev
Status: Needs work » Reviewed & tested by the community

Looks it good time to get commited

andypost’s picture

Status: Reviewed & tested by the community » Needs work

does not mean to change status

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

andypost’s picture

Only readme fixes are left here

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

alexpott’s picture

Note in some ways the argument about whether this should be included in core is not somewhat moot. In the new composer project templates we have:

        "installer-paths": {
            "web/core": ["type:drupal-core"],
            "web/libraries/{$name}": ["type:drupal-library"],
            "web/modules/contrib/{$name}": ["type:drupal-module"],
            "web/profiles/contrib/{$name}": ["type:drupal-profile"],
            "web/themes/contrib/{$name}": ["type:drupal-theme"],
            "drush/Commands/contrib/{$name}": ["type:drupal-drush"],
            "web/modules/custom/{$name}": ["type:drupal-custom-module"],
            "web/themes/custom/{$name}": ["type:drupal-custom-theme"]
        },

So we have a type drupal-library that gets put in the libraries directory. And Lightening and Thunder (and probably every other distribution) creates a libraries folder during its installation.

So this issue really is should we add a README to this folder and what should it say.

SKAUGHT’s picture

SKAUGHT’s picture

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

needs-review-queue-bot’s picture

Status: Needs review » Needs work
FileSize
209 bytes

The Needs Review Queue Bot tested this issue. It either no longer applies to Drupal core, or fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

Apart from a re-roll or rebase, this issue may need more work to address feedback in the issue or MR comments. To progress an issue, incorporate this feedback as part of the process of updating the issue. This helps other contributors to know what is outstanding.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.