Problem/Motivation

In naderman & RobLoach's presentation at DrupalCon Munich, it was recommended that Drupal core become a dependency of Drupal. This would allow end-users to modify Drupal's composer.json file, while at the same time maintaining Drupal core's own composer.json file that would not be touched.

Proposed resolution

Permanently split Drupal and Drupal core into two separate, distinct repositories/projects.

This setup is similar to the architecture imposed by Symfony and Symfony Standard as well as Laravel Framework and Laravel.

In the same way we'd have "Drupal" and "Drupal Core".

Remaining tasks

Packaging Script should maintain a complete package of Drupal that combines both repositories. This can be easily accomplished by executing composer install from the Drupal repository before the package is built.

API changes

Every 9.0.x patch will need to be re-rolled against the appropriate repository.

Comments

Mile23’s picture

davidwbarratt’s picture

FYI:

I mentioned this issue in my session at DrupalCon Los Angeles: Using Subtree Splits to spread Drupal into everything

timmillwood’s picture

This makes sense, maybe it could go in before 9.x?

davidwbarratt’s picture

#3,

I mean it's whenever we want to re-roll / re-write every patch in Drupal core out there... I think that would take a while, but I guess it could go out before 9.x, but not before 8.0.0. Since the packaging of Drupal will remain the same, I don't think it's immensely disruptive to Drupal users, just Drupal contributors.

catch’s picture

Status: Active » Closed (duplicate)
davidwbarratt’s picture

Status: Closed (duplicate) » Active

Not a duplicate, I created both issues and they cover separate topics. This one covers having two completely unique repositories (i.e. not a subtree split)

davidwbarratt’s picture

Version: 9.x-dev » 8.1.x-dev
catch’s picture

Category: Task » Plan
Priority: Critical » Major

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.0-beta1 was released on March 2, 2016, which means new developments and disruptive changes should now be targeted against the 8.2.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.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.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.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.

alison’s picture

Hi! I'm reading up on a lot of composer-related d.o discussions. @davidwbarratt and @timmillwood is this still something you're thinking about / wanting to do (if you had time har har har), or not really anymore? Thanks!

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.

Mixologic’s picture

Status: Active » Closed (won't fix)

We now have subtree splits of drupal, giving us separate repos for core/ and components, and I think we definitely want to continue to follow symfony's lead with the monorepo/manyrepos concept, especially because we dont want to develop multiple policies and manage multiple 'project repos'.

Im going to wontfix this, and if anybody disagrees, they can protest and reopen.