#3074993: Use "current" in update URLs instead of CORE_COMPATIBILITY to retrieve all future updates we are switching to a new XML feed from drupal.org that provides supported_branches instead of supported_majors and some other metadata changes.
#3074993 is changing to this new XML feed but keeping the current functionality based on majors. For instances if:
<supported_branches>8.7.,8.8.x</supported_branches>currently 8.8.0 will be the recommended release even 8.7.10 is still release on a supported branch and doesn't require jumping to the next minor version of core which can be disruptive.(this will be the same after (#30749930)
Currently this does not affect contrib because support branches are the same as minors. this will change when #2681459: Support contrib semver releases is done.
The update module should recommend the latest release for the current branch if it is still supported. It should also indicate there is another release on the next supported branch.
Determine if this is the desired functionality
User shown updates by supported branch
Comments
Comment #2
tedbowComment #3
drumm#2189131: Update DrupalorgVersioncontrolLabelVersionMapperGit for semantic versioning in contrib is a blocker here, at least for Drupal.org support. As that issue is done, Drupal.org will have a sample contrib project using semver.
#3074993: Use "current" in update URLs instead of CORE_COMPATIBILITY to retrieve all future updates remains the most important core blocker.
Comment #4
webchickBased on the #d9readiness meeting, this one's a biggie, as it impacts semver support in contrib.
Comment #5
catchIt looks like #3111929: If no recommended update is found, Update Status recommends the latest release, even if it is unsupported will fix the beta-blocking part of this (i.e. update status recommending unsupported releases of core).
This issue then would be a blocker to proper semantic versioning in contrib (i.e. 3.0.0 releases) - which is still critical but not beta blocking.
So... tentatively untagging but please re-tag if necessary.
Comment #6
xjmI'm not sure this is not still a beta blocker. We need 9.0.x and 8.9.x to support full semver for contrib, which is listed as a "should have" on the beta blocker list. If this issue involves API additions or changes, it would have a beta deadline.
We could choose to commit it during beta and potentially consider backport to 8.8 as well, but I'm concerned about descoping this too soon because we're likely to run into d.o bugs as we fix it and it it should be in 9.0. I do agree the other issue should be fixed first.
Comment #7
xjmComment #8
xjmI'm going to re-tag it for now so we don't lose track of it, but we can still descope it later if we decide it's appropriate.
Comment #9
drummI think it is okay to not go as far back as possible for this one. When we do open up semver versioning for all of contrib, we’ll have to put in documentation/warnings that let maintainers know they will only be supporting 8.9+, or wherever this lands.
Comment #10
xjmComment #11
dwwSeems related to #2990476: If the site is on an insecure version of an old minor and there is a secure version of that old minor available, the update status report should link that release. Don't yet fully understand the scope of each issue, but they seem to be talking about very similar things...
Comment #12
catchGoing to go ahead and mark this duplicate of #2990476: If the site is on an insecure version of an old minor and there is a secure version of that old minor available, the update status report should link that release.