How to deprecate or archive a project or declare it obsolete?

[indigoxela]

Currently we have 1.4k+ projects available on GitHub.

As long as they have at least one stable release, they show up in the Project browser on admin/modules/install, to conveniently install them via admin UI.

We also have the bug-squad available to help with projects with slow or no maintenance.

And there's a defined procedure to take over maintainership of abandoned projects.

What we do not have, is the ability to prevent showing a project up in the Project browser (and also in the add-ons listing). We'd have to:

1. Completely delete the entire repo or at least every single release
2. Ask someone with sufficient permissions to delete the release nodes on B-org

In other words, there's no way to deprecate or archive a project (or project branch) without wiping it out entirely.

This issue exists, so we can discuss expectations and collect use-cases for that.

[indigoxela]

To me as project maintainer of several modules and themes, this seems like a shortcoming.

How about a project, that's clearly obsolete? (maintainer perspective)

Example 1: module B has been merged into module A, so B's now obsolete, but fine when installed with an older version of A. But new installs don't make sense anymore. And it's still OK to keep the code history on GitHub.

Example 2: a module depended on a 3rd party service, which doesn't exist anymore. So this module's useless. However, a new site admin on a site not updated for a long time would appreciate the project page on B-org, so they know what this module did (and most of all, where it came from).

How about truely abandoned projects? (site admin perspective)

Example: as PHP moves on, very old code will break at some point. This can even lead to modules, that break the site immediately when installing them (via project browser).
The bug-squad can surely help in that case, but only if someone provides a PR or tests... But what if nobody bothers, for example if the project provides no real value anymore?

A clear procedure for those "rotten tomatoes" could be pretty helpful to prevent breaking sites with them. Such a "rotten tomato state" could be temporary, BTW.

[indigoxela]

So, what I'd like to have is:

• A way to hide my own project from project browser, while keeping its project node on B-org (keep release and git history)
• A way to officially mark a project as deprecated: to hide it from project browser and clearly (visually) mark it on B-org and also for existing installs on site's admin/reports/updates (to raise site admin awareness)

^^ I see these two things as separate options for different use-cases.

[izmeez]

Does the Project Browser have tags that govern its behaviour? Can some extra tags be added?

Deprecated may be an easy option and could include link to the newer option.

Old, unmaintained projects start to go down a slope. Some may still be useful but depend on external libraries that are no longer being maintained, or have php that is severely outdated. There are progressive dangers where a series of tags could be helpful and eventual a tag where the project is unavailable for install, unless someone does so manually from the github repo.

[yorkshire-pudding]

How about a new optional status property for .info files? As the project browser, the project module on b.org and bee 🐝 parse the .info file then there are logical places to add the handling of this new property.

It could be a multi-value property where NULL (i.e. not set) or status[] = active means it available for install.

The reason that multi-value could be beneficial is if there could a status[] = inactive or status[] = deprecated along with an additional status or more to capture the reason. For example:

• 3rd_party_library_obsolete
• merged_to_core
• merged_to_other_module
• fatal_errors

This could be used in project browser and b.org in the ways described and bee could do a warning and/or an override to download such projects.

This has the advantage that maintainers and bug squad are in control and there can be a clear history on the project as to what happened and why; the places it is used just adjusts when it finds this status.

[indigoxela]

How about a new optional status property for .info files?

That sounds promising. Edit: nope, not ideal...

Ideally as simple as possible, a single string... 🤔 And totally optional, so no value at all means "default behavior as currently".

status (or project_status?) might be one of...

• hidden
• obsolete
• deprecated
• archived

So an info file like:

type = module
name = My Module
....
status = hidden

would simply prevent it from showing up in the project browser.

While an info file like:

type = module
name = My Module
....
status = deprecated

Would also change the way the module's displayed on admin/reports/updates/list
Not sure what it would look like when there's both - an update available, but deprecated in the meantime.

[indigoxela]

Hm, wait a minute... if it's the info file, wouldn't there be the need to roll out another release to deprecate a project?

Dang... 😞
Or am I missing something?

[yorkshire-pudding]

Hm, wait a minute... if it's the info file, wouldn't there be the need to roll out another release to deprecate a project?

Dang... 😞 Or am I missing something?

I think you are probably right on that

[yorkshire-pudding]

How did Drupal 7 start marking projects as unsupported?

[indigoxela]

How did Drupal 7 start marking projects as unsupported?

I belief, they did/do it via project node fields (properties), but Backdrop maintainers usually have no access to edit that node on B-org.

However, on B-org there's a job to fetch the README from GitHub - maybe we could extend things that way... 🤔
The README contents (so, project node contents) get updated via cron - independently from releases.

[yorkshire-pudding]

Yes, it would work better, IF we could ensure consistency; might need the Bug squad to help if when people get the syntax wrong.

[indigoxela]

...might need the Bug squad to help if when people get the syntax wrong.

I don't think, it's a good idea to put it into the README (which is free text form). If there's a way, I'd prefer something more structured. Like a specific file in the main repo dir... Not sure if that would work.

What happens if a project has a supported and an unsupported branch?

But maybe we're a bit too early with discussing technical approaches, while we still didn't settle on what we need (which options and what the outcome should be)? (No, that's no invitation for bike shedding 😆 )

[yorkshire-pudding]

One thing to consider is that a working module, even if obsolete/deprecated, may still be useful for D7 upgrades whereas a completely broken module wouldn't be. Therefore, would it be important to make that distinction?

[indigoxela]

a working module, even if obsolete/deprecated, may still be useful for D7 upgrades...

Sure, the libraries module for example. Yes, there should be distinction.

Broken projects are probably a tricky topic. Who decides, what is broken? How to figure out, whether a tomato is a bit muddy or is totally rotten? 😁 Such impressions can be pretty individual and might even depend on environments (like PHP version)... An active project maintainer should be able to set such a state on their own project, I guess, but who else should be allowed to and under which conditions?