Contrib.social

Consider always having the next major branch open

Open on Drupal.org →
Created on 17 March 2025, 20 days ago

Problem/Motivation

I think this has been discussed a couple of times before, but don't think there's an existing issue for it.

We tend to open the next major branch (12.x will be the next one) when there are 'meaningful' changes from the previous minor branch - this usually means a new major Symfony version or some other dependency update.

At that point, we then start removing old updates and deprecated code etc. from the new branch.

An alternative approach would be to always have the next major branch open, and commit breaking changes to it as we go along, this would affect the following:

- deprecation removals
- type hints and other bc breaks not included in deprecations
- module removals
- probably not old updates because update tests are very hard to update due to db dumps needing to be refreshed to stay in sync, these still might need to be timed.

Advantages:

Contrib could switch on 'next major' at any point, and get phpstan failures on an ongoing basis. This could help with some bc-breaking changes that are hard to warn for in other ways like type hint changes.

Disadvantages:

Changes to constructors and similar things that we provide bc for would need two MRs before the original issue can land - the next major one with no deprecations, and the current major one with deprecations included. This is more work for the original task/bugfix etc. whereas we currently remove a lot of deprecated code in a handful of sweeps across core, so it could result in more friction getting issues done in the first place.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

🌱 Plan
Status

Active

Version

11.0 🔥

Component

other

Created by

🇬🇧United Kingdom catch

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @catch
  • Comment 20 days ago →
    🇬🇧United Kingdom catch

    One way to avoid having two versions of an MR would be to just not require it for the next major commit, so there's still some deprecated code committed in those cases. This would still allow other breaking changes like type hints to go in straight away.

  • Comment 20 days ago →
    🇺🇸United States cmlara

    I wan to reiterate this just essentially opens the 'next major' split early, we do so every major release so the process isn't abnormal in that regard. IMHO this tends to align with having a MAIN branch which is intended to eventually be done for core.

    Pros:
    New API can be implemented immediately.
    No need to postpone API breaking change or major system overhauls to branch split (issues can be worked on when devs have the time rather than crushed into a shortened release window)
    Ecosystem can begin testing with the new major, as it will exist, much sooner (possibly reducing the number of critical bugs to fix during alpha/beta). This goes beyond just phpstan
    Less followup tickets (possibly less cluttered issue queue).

    Cons:
    An additional branch to maintain.

    One way to avoid having two versions of an MR would be to just not require it for the next major commit

    Considering we have a fairly standardized deprecation format, It may be possible to work the issues with deprecation and let rector strip them to create the mainline MR. Could be tested and possibly become an "on commit" task if it proves reliable.

    Addtionaly a healthy workflow inside MR can make it easier if developers separate deprecation from non deprecation it could be a simple re-base with excluded commits. This would take a bit of training however is reasonable to expect long term we could accomplish this.

    We almost somewhat have the work already separated, I frequently see issues get through review to only later get tagged "need deprecation" before the issue can be committed. For those issues it is not much more effort to cherry-pick the current work based on the mainline branch on top of the released branch and add the deprecation.

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024