Consider adding a new abandoned lifecycle status

Created on 19 July 2023, 7 months ago
Updated 13 February 2024, 12 days ago


In πŸ“Œ Lower the bar for module adoption for Drupal 10 Active we're discussing ways to ease the update process between majors for site owners.

One idea is

We come up with an official group for module readiness. With a defined remit outlined in governance policy somewhere.
This group has the ability to commit automated patches and make dev releases on any project where [conditions to be determined that unblock a module upgrade]
We have some prior art here eg The security team can edit any project page within their purview.
The group has an official process for membership and voting on whether to intervene. E.g let's say they need 3 +1 votes from members of said group to intervene. All of this is communicated on the relevant issue for each module.
The process would be that group temporarily edit maintainer list to add one of themselves, make the commit and release, then remove, again documented on the relevant issue

One of the flagged issues with this is it gives site owners a false sense of security that the module they use is actively maintained.

As part of that the discussion led to an additional part of this process being

  1. The readiness group adds a 'seeking new maintainer' issue to the issue queue of the module
  2. The readiness group set the lifecycle status in the info file as abandoned and the lifecycle link to point to the issue link from 1) above

Proposed resolution

Add a new lifecycle status abandoned.
Treat this the same as deprecated - show a warning in the admin/modules page and in the status report

Remaining tasks

Agree on this approach
Code it up

User interface changes

API changes

Data model changes

Release notes snippet

πŸ“Œ Task



11.0 πŸ”₯

BaseΒ  β†’

Last updated 1 minute ago

Created by

πŸ‡¦πŸ‡ΊAustralia larowlan πŸ‡¦πŸ‡ΊπŸ.au GMT+10

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

Comments & Activities

  • Issue created by @larowlan
  • πŸ‡ΊπŸ‡ΈUnited States mglaman WI, USA

    It'd interesting if this could also be automatically added to an info.yml during packaging based on branch status or the module's actual "unsupported" status as well.

    Then it's not just up to the "major upgrade fixer team" to ensure it is set for nearly abandoned modules.

  • πŸ‡ΊπŸ‡ΈUnited States Kristen Pol Santa Cruz, CA, USA

    Pasting my comment from slack:

    One thing that someone commented on when I created the "abandoned project/module" spreadsheet a while back was that they didn't like the word "abandoned" because it could just be the maintainer was busy with other things for a while and was planning on coming back to the project/module at some point... I ended up updating the spreadsheet/sub-initiative wording to switch from "abandoned" to "adoption".

    So... we may want to consider something other than "abandoned" ... i.e. "Needs some love" :D

  • πŸ‡ΊπŸ‡ΈUnited States drumm NY, US

    It'd interesting if this could also be automatically added to an info.yml during packaging based on branch status or the module's actual "unsupported" status as well.

    I don’t think we’ll be adding anything additional to .info.yml in packaging due to issues like πŸ“Œ Packaging info from .info.yml often creates conflicts when patching (ddo) Active . (We could add a separate metadata file as mentioned in that/related issues.)

    Composer already has a standard for marking abandoned packages: Since this proposal looks like it is about projects, not individual modules within projects, I recommend using the standard from Composer.

  • πŸ‡¦πŸ‡ΊAustralia larowlan πŸ‡¦πŸ‡ΊπŸ.au GMT+10

    #3406954: Proposal - create a 'Project Update Working Group' β†’ is RTBC so we need to decide if we want to

    • go ahead here OR
    • leave things as they are OR
    • convey abandoned via composer.json
Production build 0.61.6-2-g546bc20