Problem/Motivation

Fantastic with the new release, thanks!

It does look like a previous version (4.0) may have had the "Supported" check-mark removed, which triggers warning email alerts ...

Email

The installed version of at least one of your modules or themes is no longer supported. Upgrading or uninstalling is strongly recommended. See the project homepage for more details.

See the available updates page for more information:
https://example.org/admin/reports/updates

Your site is currently configured to send these emails only when security updates are available. To get notified for any available updates, https://example.org/admin/reports/updates/settings.

Under Available updates

Release not supported: Your currently installed release is now unsupported, and is no longer available for download. Uninstalling everything included in this release or upgrading is strongly recommended!
Includes: Menu migration (Import & Export)

https://example.org/admin/reports/updates

Steps to reproduce

Get email warnings about security update, see warnings on Update page.

Proposed resolution

Set 4.0 to "Supported", since it works fine. It's just not the latest release.

Remaining tasks

I tried to raise this issue, but it seems like the interface still does not convey the consequences of removing "Supported" effectively?

User interface changes

API changes

Data model changes

Comments

ressa created an issue. See original summary.

bbu23’s picture

bbu23
Location 🇪🇺🇪🇺🇪🇺
commented
Status: Active » Fixed

Hi @ressa,

Thanks for opening this issue. I see, I forgot that marking a branch intended for minor releases causes this "chaos".

It's a bit unfortunate because I'm trying to closely follow the Semantic Versioning format which kind of forces me to create a minor release if there's at least 1 backwards compatible feature in the package. This means that because of the way Drupal handles releases, I am obliged to keep two or more releases in the project page instead of having just one (when it makes sense).

For example, it made sense to have version 3 and version 4 in the project page until version 3 was marked as unsupported.
But it seems that if I provide 3 or 4 minor releases in version 4 in a short time, I might have to keep all of those in the project page (at least for a few weeks).

I'll have to read through the related issues to see what others think/say, but personally I'd love to have a way to say "this is a minor release, don't spook everybody" and show only the latest release in the project page to avoid creating confusion. A separation from "supported" and what's shown in the project page. Of course, in some scenarios we might want to keep 2 releases from version 4, but this should be a choice of the maintainer.

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.

bbu23’s picture

bbu23
Location 🇪🇺🇪🇺🇪🇺
commented

I added info on the Menu Migration project page about the 4.0.x version EOL timeframe. I think 2 months is more than enough. Thanks @ressa

ressa’s picture

ressa
he/him
commented

Hi @bbu23, thanks for a fast response to this, and just altogether creating and maintaining this great module.

I agree, that it's unfortunate that if you follow SemVer recommendations diligently, you can end up with multiple release on the project page, very close to each other, only increasing with a minor version ... It might almost nudge a project maintainer to squeeze as many backwards compatible features as possible into a release, resulting in a not exactly optimal situation.

But it's great that the previous version is now set to "Supported" in the project GUI's settings, since it means that Drupal administrators will not receive nagging update emails about a security issue, weekly or daily.

Two months should be enough to allow users to update. Though it could be extended until Summer, if it's not exactly problematic maintenance-wise for you? I'll let you be the judge about that :)

I agree that it would be nice if you as a module maintainers had more control over displayed versions ... maybe something like these options could work? It might also make it clearer that EOL, will result in warning emails.

Version 	Project page  EOL
4.1      x                    <<< Show on project page
4.0                           <<< Do nothing
3.3                    x      <<< Send email alerts

I tried raising this in #3509377: False warnings about security updates and via #686918: Add help text to project release admin page to warn about marking branches unsupported and the impact on update status this was added. It does describe the situation precisely, but maybe not everyone reads it?:

“Supported” generally means you will resolve security issues when contacted by the security team, fix bugs when you are able, and any additional support you would like to provide as a maintainer.

When a release series is unsupported, site maintainers using affected versions will be alerted that they are running unsupported software. It is best to give people at least a few weeks to upgrade by leaving two release series supported. It is also ideal to keep supported versions that cover compatibility with all currently-supported versions of Drupal core.

https://git.drupalcode.org/project/drupalorg/-/commit/fa78028cf6abee248a...

PS. Congratulations on reaching +1'000 installations! 🎉

bbu23’s picture

bbu23
Location 🇪🇺🇪🇺🇪🇺
commented

Hey @ressa,

It might almost nudge a project maintainer to squeeze as many backwards compatible features as possible into a release, resulting in a not exactly optimal situation.

👆I agree with this hehe.

Yes, it's great for the administrators. Thanks again for the heads up!

Two months should be enough to allow users to update. Though it could be extended until Summer, if it's not exactly problematic maintenance-wise for you? I'll let you be the judge about that :)

I researched what was the recommended time, and it was too subjective; reason why after giving it a careful thought I came up with 2 months. Though in your comment and in the releases administrative page it is suggested "a few weeks" as well. I think I'll keep the 2 months as a reference, and I'll review the usages when the time comes. If I see that the percentage is not good enough, I'll extend it. I'm planning to have 4.2.0 sometime in the near future 🙈.

I think the option you described to be able to choose which versions to display would be great! I see a scenario where I could have 4.0, 4.2, 4.3 and 4.4, none EOL yet, but on the project page I choose to show 4.4. And then if the security team contacts me or a critical bug is reported I can respond and address. And this also gives insights of the usages and we as maintainers can decide based on numbers when's the best time to set them as EOL. Plus, when using "composer outdated" the patch & minor versions are grouped together (color red), and updated the same. Only major versions have special treatment. And composer always shows the latest version, why not Drupal project page too?

Thank you for raising those issues to help make Drupal tools better for everyone. I'm afraid that yes... there can be moments when people don't read the message - unintentionally ofc. And I might have to count myself in, my eyes must've skipped it 🙈 - u think it's just the usual stuff, usual flow... a task very familiar to u...

PS. Congratulations on reaching +1'000 installations! 🎉

Thank you!🎉 It's great reaching this milestone! Reason why it was also time to change the name. Perfect timing with the release of the clone feature.
Btw, your valuable feedback since the first alpha versions up until version 4 and present contributed a lot to this achievement, and I thank you for that.

ressa’s picture

ressa
he/him
commented

Thanks for giving it some consideration @bbu23, your plan about evaluating the percent on the previous version makes total sense. Imagine if 90% are still on the previous version, when April comes around? :) And yes, about 4.2 -- that'll be an interesting addition to the mix!

I am glad to hear that my UI suggestion could possibly improve the project maintainer experience ... the question is, if it's possible to do, without too much work. Ideally it's just a matter of renaming the categories. But maybe it would take a bigger effort? I can try to share it in the issue, and see what Drupal infrastructure admins think about it. But ah yes, there's also Composer's behaviour to consider ...

The number of installations is certainly nice, but I think simply a testament to the quality of the module, and that it solves a very real challenge very elegantly. I am glad to hear that my contributions may have helped improve it, thanks for being open to my suggestions :)

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.