Release series should follow major version for contrib projects

If 2.x were supported, and you were up to 2.6.0 being released, that would mean you are making 7 security releases since 2.0.x, 2.1.x, etc are all supported.

We could automatically mark new release series as supported, so there is one less thing to remember.

> If 2.x were supported, and you were up to 2.6.0 being released, that would mean you are making 7 security releases since 2.0.x, 2.1.x, etc are all supported.

That would be the behavior if we just treat this as automatically supporting a new minor but still treat each minor thing as it's own release series.

But if you compare that with the old release scheme for contrib, then 8.x-2.6 would just have one security release: 8.x-2.7, as there are no patch releases anyway there.

Does it really have to be different for semver branches?

If a site has 2.4.0 installed, and there is a 2.6.1 security release, that just means they have to update to that version?

I think contrib is currently doing way too many patch releases that really should be minor releases (new features, dependency changes, ...), mostly because doing minor releases is too much work.

Contrib and core use the same semver spec. The legacy version numbers should not have an effect on how the spec is interpreted.

> Contrib and core use the same semver spec.

I'm honestly not sure what that means in this context. For me, this is more about release schedule/management and no, I don't think core and contrib follow the same rules here. Core has reliable, time-boxed minor releases every 6 month and patch releases between. Very few contrib projects have a similar pattern, some have minor and patch releases, but even then it's pretty adhoc and not following a predefined schedule.

Most contrib projects only do a release every few months or so (or less) and it's usually a mix of features, updated dependencies and bugfixes, in other words a minor release. Forcing workflows that makes sense for core on contrib IMHO causes projects to not follow semver. Take https://www.drupal.org/project/google_analytics/releases/4.0.2 → as an example, that's a patch release that changed the which core version (https://git.drupalcode.org/project/google_analytics/-/commit/9480a206ef3...). I'm pretty sure that is not allowed in a patch release. But creating new minor releases is inconvenient, so the maintainer chose to not do that. And that's not even a project with (only) a 2.0.x branch, where it would be quite a bit more tedious.

Found this comment from you on https://github.com/composer/composer/issues/8272#issuecomment-1770578814 (I'm not stalking you, I swear ;), which says:

> It's hard to see, but the checkboxes for 8., 9., etc are disabled. So for determining "support", every release is in one and only one series for determining support. For example, if 8.* were "supported" and 8.1.* were "unsupported", we don't want to think through what takes precedence, so we just make supporting 8.* impossible. (7.* is a special case since we didn't use semantic versioning for that series.)

Not supporting that at the moment because it would add more complexity to drupal.org/project module seems like a valid argument to not do this. This feature request (think this is a feature request, not a bug report as it is currently set) is at least some maintainers telling you that we believe it would be valuable to support and would save us time in maintaining our projects :)

Your comment also includes this bit:
> The one rule we have for Drupal projects is that if a security issue is reported against a supported release, that's covered by our security advisory policy - that issue needs to be resolved by the maintainer

You didn't specify what exactly "needs to be resolved" means. I'd argue that already now, nothing stops me as a contrib maintainer to remove the supported flag from a some release series between a security being reported and a release created when following the current behaviour and having multiple supported series.

I'm with @drumm on this one.
If one is going to publish "2.*" as supported I expect (as a site owner, and module maintainer) that a release will at a minimal release security fixes for EVERY 2.* release, and ideally you should be releasing bugfixes. If this was a setting that wasn't public exposed on the API (make sure 2.x doesn't ever report supported) and only worked in the backend that would reduce that concern.

For me, this is more about release schedule/management

It really doesn't have anything to do with scheduling, it is about indicating what the release contains.

Most contrib projects only do a release every few months or so (or less) and it's usually a mix of features, updated dependencies and bugfixes,

I think that is what most of us as a community hope will change going forward.

I'm aware of at least one maintainer who has said they adopted semver numbering solely because they wanted their module to look 'well maintained' and they had no intention of complying with semver. I suspect other mainteinrs are not as callously using semver numbering and may just not have a good understanding of how to best take advantage of it.

It has been floated that maintainers should consider bugfix releases more frequently, even possibly moving to daily releases as some projects outside of Drupal have. Part of this would need some work on D.O. for an API to accomplish. However absent an API more frequent bugfix releases may not be bad for the ecosystem.

I'm still working to get all my projects to semver, and yes it increases maintenance burden to run multiple branches, however I believe also provides a more reliable choice to site owners to work with. I really want to see more adoption of this going forward. In my case there is no scheduling timeline for any of the releases on contrib, they occur when deemed necessary. I likely should be making more frequent patch releases.

I'd argue that already now, nothing stops me as a contrib maintainer to remove the supported flag from a some release series between a security being reported and a release created

It is apparently an undocumented policy to prohibit marking a branch unsupported while an open security issue exists, even if the EOL has been previously announced before a security issue was reported. #3312483: Codify and enforce rules regarding marking releases unsupported → was opened to try and work on that issue. Note that Drupal Core does not adhere to this policy.

I received a decent scolding for following previously announced EOL dates and had to revert the support status for a few hours to tag the security release. Note: the release was always intended to be published because the report was made prior to the EOL date occurring.

as an example, that's a patch release that changed the which core version

This probably isn't the best example, the subject is rather hotly contested in the contrib community. It ranges from dropping core can be done in a patch, to dropping core can only be done in a major depending upon do you view Drupal Core as a supported operating environment or just a dependency.

🌱 Guidelines for semantic versioning and Drupal core support Active has some discussion on this subject as does Slack.

I agree with berdir here - pretty much every contrib release is a minor release and the availability of patch releases is a nice to have but not even necessary for most cases.

It seem like a "series" of releases used to be based on an actual git branch?

If I want to have the behavior currently being forced here I'd expect to need to create 2.0.x, 2.1.x, etc branches for each minor.

The fact that I have to specifically flag the old minor as supported and have it show on the project page seems especially weird and terrible. I don't need it to be unsupported unless it has a security vuln, but I certainly don't want it to show as a suggested download.

@drumm could you point to the code involved in project module? Is there some way we could make it possible to pick the release "series" when I'm making a new release?

Not supporting that at the moment because it would add more complexity to drupal.org/project module seems like a valid argument to not do this. This feature request (think this is a feature request, not a bug report as it is currently set)

Yes, this complexity is what I hoped to show without typing up the reasoning for the current system again. And agreed this is very much a feature request.

If one is going to publish "2.*" as supported I expect (as a site owner, and module maintainer) that a release will at a minimal release security fixes for EVERY 2.* release, and ideally you should be releasing bugfixes. If this was a setting that wasn't public exposed on the API (make sure 2.x doesn't ever report supported) and only worked in the backend that would reduce that concern.

If we hypothetically said we do make this feature change, and if a maintainer “supports” 2.*, and we want that to actually mean only 2.6.* is supported when 2.6.0 is released. Then 2.0.* through 2.5.* are unsupported, and we’d want to show the same in the update status API. So as soon as 2.6.0 is released, sites using 2.5.0 say they are using an unsupported release. Or we could tell update status 2.* is supported (testing core to make sure that works as intended) and then sites could be all the way back on 2.1.0 with no alerts about missing support or a larger upgrade if there is a security release. Neither seems kind to site owners.

It seem like a "series" of releases used to be based on an actual git branch?

The “series” is implemented as removing everything after the final dot in the version number.

If I want to have the behavior currently being forced here I'd expect to need to create 2.0.x, 2.1.x, etc branches for each minor.

For most projects, I recommend using a 2.x branch, and make all 2.x.y releases from that. Support the 2 most recent release series at a time, so site maintainers have some time to upgrade to the most recent minor version. If you have long pre-stable cycles, maybe support 3 release series. (Supporting an unstable release doesn’t promise a lot practically, anyway.) If there is a security release, or an important backport, and two supported release series need to diverge, then make the 2.5.x branch starting from the 2.5.0 tag. Otherwise, your commit history is a straight line for the entirety of 2.x.

If we were to figure out how this translates into the update status API, and communicating expectations for site owners, I also fear getting the UX improved to explain all of this to contrib maintainers, since it would be additional configuration and option. And we are avoiding adding any unnecessary complexity to our codebase before upgrading the site past D7.