Remove “recommended” status for releases?

Umm, point of order.

How did you expect to get feedback for this proposal, before making this change? I never knew about this until it was committed and deployed. Apparently no one else knew about it either, because there have been no comments either pro or con.

I maintain modules that collectively are used on over 250,000 Drupal sites. I didn't know about this change until it happened. Yes, I am subscribed to all the relevant notification channels on drupal.org, and I can't possibly know about or follow every single issue queue that might affect me and the users of my modules. I do not participate in the "project" issue queue, and without checking this issue queue I apparently have no way of finding out about changes like this until they are already a done deal.

It seems to me that you should have solicited input from people like me before you made this change. Maybe via a maintainer's mailing list or some such mechanism. I *am* subscribed to the maintainer's mailing list, but I have never received any information through that channel.

The problem with this change is:
I have some project that now show TWO valid releases, rather than ONE "recommended" release (green) and one not-recommened (yellow) release which exists only for backwards compatibility. How do I distinguish between these two releases? And how to I mark one release as recommended over the other? Do I need to unpublish the older release? But the older release is still relevant for backwards compatibility, so how do I deprecate the use of the older release and encourage users to move to a current release, without having to cut them off entirely?

On a related note (this issue was a spin off of 📌 False warnings about security updates Active ) I am not sure if the module maintenance GUI got updated, and a warning about the potential consequences of removing "Supported" check mark was added, see #686918: Add help text to project release admin page to warn about marking branches unsupported and the impact on update status → .

But the current set up can sometimes results in false alarms, where a very small update gets released in a new version, and a seemingly innocent change in the UI by the maintainer (remove "Supported" check mark) results in security alerts emails to all the end users. So we should make sure that maintainers are aware of the potential result of this change.

Sorry for the abruptness of this change. This is something I’ve been mentioning in other issues, but should have had its own issue earlier. The timing is actually prompted by ✨ Support confidential issues in git.drupalcode.org for security team triage Active , it would be good for the new.drupal.org automations to post an automated comment including what versions of the project with a potential security issue are currently supported. So we need to migrate this data to the new site. Before migrating, we’re simplifying so there is less to migrate and less UI to port to modern Drupal when we get there.

This issue will remove the option to designate releases as “recommended” once it is complete. It will be the last thing to go, once everything that depends on it is removed. That will simplify the page and will be a good opportunity to follow up with #686918: Add help text to project release admin page to warn about marking branches unsupported and the impact on update status → in the near future.

People should see the higher version number, that’s a stable release, as the recommended version. “Recommended” was never communicated to Composer, or update status. So it was only ever shown on project page, many people might not have seen it for some time.

lifecycle: in .info.yml files may be a good way to communicate deprecation of old versions: https://www.drupal.org/docs/develop/creating-modules/let-drupal-know-abo... →

This is now all deployed.

With this change this page is outdated: https://www.drupal.org/docs/develop/git/git-for-drupal-project-maintaine... →

It still references "recommended" releases. I'm editing the page to indicate the problem, but I'm not confident enough to edit it.

I made some edits to that page to remove references to "Recommended" and adapted the language a bit.

One minor point is that it is a little hard to determine (for non technical or novice users) which version they should be using. For example:

https://www.drupal.org/project/entity_clone →

Both are the same color and at a glance look basically the same, 2.1 is D11 compatible though. But there are projects out there that may have two major version branches running in parallel, but one is the 'recommended' one to use. Maybe some visual cues or improvements can be done to help distinguish beyond blue tinted release boxes.

Isn't for accessibility colour should not be the only difference in the meaning of the links?

GitHub has tags for different releases:
https://github.com/vercel/next.js/releases

For the entity clone example I think more use could be made of the 'short description' field. From looking at a couple of different contrib pages, it looks like people tend to use that has a heading for the specific tag, whereas it could/should be used more as a description for the entire branch.

For core's active branches we use:

Actively maintained with new features and backwards-compatible improvements every six months. Use this version for the best compatibility with future releases.

For security branches, variations on:

Drupal 11.0.x will receive security coverage until June 2025 when Drupal 11.2.0 is released.

Contrib short descriptions aren't as prominent as on the core download page, but that seems like the right place to put the information.