Remove drupal/legacy-project as a starting point for Drupal 10

Moved to MR

I applied patch 14 and corrected wrapping and a duplicate letter. Attached is a diff.

Looks ready

Are we going to do this in the D10 cycle or should we wait until 11.x is open for development and remove it only in 11.x releases?

If #10 is correct we need to actually stop trying to create tarball releases of core via the packaging script altogether, before we break them.

I believe tarball packaging depends on this https://git.drupalcode.org/project/drupalorg/-/blob/2647a1a82a012af30376...

And we’d have to check if this is hard-coded anywhere in subtree splitting, https://bitbucket.org/drupalorg-infrastructure/subtree-splitter/src/master/

@drumm from the DA end what do you think about removing core tarball packaging from 11.x onwards? We'd need to keep the 10.x tarballs probably, unless we do it purely by a date cut-off.

Sure, either policy works. We can get the packaging pipeline, including subtree splits, running on staging and try out this change, so we have less of a chance of debugging in production.

I posted to #3285191-18: [meta] Deprecate tarballs, because they are incompatible with Composer-managed dependencies, Automatic Updates, Project Browser, and release managers' health → a prominent place we’ll need to update, https://www.drupal.org/download →

I tried out the subtree splitter a bit on staging with the diff from the MR. As far as I can tell, it works okay.

The subtree splitter is not a blocker.

I expect more of the parent plan needs to be done before proceeding, this seems like one of the final steps, so leaving this postponed.

Tarballs are going to be removed so we can finally do this for Drupal 12.

Also I wonder if we can mark this as abandoned in Drupal 11 - so people would get a message if they used it by mistake. Hopefully doing that would not break packaging.

Opened 📌 Mark drupal/legacy-project as abandoned Active to mark it as abandoned which hopefully we can do before Drupal 12.

Hopefully doing that would not break packaging.

I’d appreciate it if we had a chance to test before potentially breaking packaging.

Since tarballs are still prominently featured on https://www.drupal.org/download → , and I haven't seen progress on the parent issue, I didn't think this was moving forward yet.

My comment in #22 here does say this will break packaging, since legacy-project is directly referenced around https://git.drupalcode.org/project/drupalorg/-/blob/2647a1a82a012af30376...

Since tarball packaging is using composer, and is a decent smoke test of subtree splits, we may want to keep it packaging recommended-project instead. The result would still be "composer-ready", so someone downloading it should be able to continue using composer as if they started with composer create-project. We can also hide the resulting tarballs. Or we do skip the step entirely if it is not a useful smoke test.

Found my way here through testing Drupal CMS on shared hosting. Many of the shared hosts provide an automated installer inside CPanel that does a one-click install of Drupal, and now Drupal CMS.

However the addition of Drupal CMS led us to figure out that the vanilla Drupal install is using legacy-project, which is almost certainly to avoid having the /web subdirectory. (Drupal CMS does install with /web, which has obvious and undesired knock on effects in the shared hosting context.)

Just noting this as something we should be aware of if we remove it.