There was only support for 1 recommended release, where the update XML documentation refers to 1 recommended release per major release. Currently any release that was tagged 'recommended' would un-'recommend' all other releases within the same project, regardless of major release number.
This could lead to a message 'not supported!' on 'admin/reports/updates' because the XML only had 1 major release number in the <supported_majors> tag. (if you were using version 1.x and the recommended release was 2.x)

This patch changes that behaviour by only unsetting 'recommended' in releases with the same major release number as the release that is being submitted.

CommentFileSizeAuthor
recommended_major_releases.patch700 byteslendude

Comments

eugenmayer’s picture

eugenmayer commented
Status: Needs review » Closed (works as designed)

well, it is by design, that you only have exactly one recommended major in a core version. So, unsetting all recommended releases in the current selected core version is what to be exepcted, and AFAICs this is done.

In your approach, it can happen that you end up having 2 recommended major branches in lets say for 6.x

Reopen if i misunderstood something

lendude’s picture

lendude
Primary language Dutch
Location Amsterdam
commented
Title: Multiple recommended versions of different major releases » Only ever one <supported_majors>
Status: Closed (works as designed) » Needs work

You are right, this is not the proper solution to the issue. Let me give a description of the issue I ran into, and tried to solve.

Example:
I have a module with version 1.4 on my fserver
My new version I put on fserver is 2.0, and set this to recommended, but not security
When I check for updates on a site running the 1.4 version of the module, I get a big red 'Not Supported!' warning next to the module, instead of a yellow 'update available' message

Problem:
The XML generated by fserver only ever shows one , namely the major of the recommended version (so all other major versions get flagged as Not Supported)

My previous patch attempted to solve this by setting more than one release to recommended, as EugenMayer pointed out, that's the wrong way to go.

I found the underlying problem in fserver_plugin_style_updatexml.inc line 149

 if ($releases[$num]['recommended']) {
   // Use the first major version for the project major.
   // The list is sorted by "major desc", this way the latest branch will be
   // recommended and all other branches (which have a recommended release)
   // will be tagged as supported.
   if (empty($project['recommended_major'])) {
     $project['recommended_major'] = $releases[$num]['version_major'];
   }
   $project['supported_majors'][$releases[$num]['version_major']] = $releases[$num]['version_major'];
 }

That last line of code should not be inside the if-loop. All releases should be added to $project['supported_majors'] not just those with $releases[$num]['recommended'].

That solves that part, but this gives rise to a new issue. If I make the change I pointed out, the 1.4 version (from my example) now shows up as a green 'up to date' instead of a yellow.
I haven't found why this would be. Any ideas?

Len