Latest release from maintainer's recommended branch called "Also available", not "Recommended"

Here's a work-in-progress. It mostly works great, without even breaking the string freeze. The good news is that, in the existing UI, if the currently installed version is the recommended release from the "target major", we never print out a "Recommended version:" line in the available updates report. However, internally, the code still expects the 'recommended' version to be from the same major version as the "target major". So, if we hit the case where we're running an older major which is still supported but no longer the recommended version, we can just record the maintainer's recommended version in a new 'maintainer_recommended' field in the project array. Then, when we're generating the available update report, if we see this 'maintainer_recommended' field, we can print that out as the "Recommended version:".

I've tested a bunch of edge cases here, and everything works with 2 important exceptions ('C' and 'G' in the following list):

A) the simple case:
- existing: 6.x-2.0, 6.x-1.2, 6.x-1.1
- recommended major: 2
- supported majors: 2, 1
- current: 6.x-1.2
* Recommended version: 6.x-2.0

B) beta exists for V1:
- existing: 6.x-2.0, 6.x-1.3-beta1, 6.x-1.2, 6.x-1.1
- recommended major: 2
- supported majors: 2, 1
- current: 6.x-1.2
* Latest version: 6.x-1.3-beta1
* Recommended version: 6.x-2.0

C) only a beta for maintainers' recommended major: [TODO: broken]
- existing: 6.x-2.0-beta1, 6.x-1.3-beta1, 6.x-1.2, 6.x-1.1
- recommended major: 2
- supported majors: 2, 1
- current: 6.x-1.2
* Recommended version: nothing // Evil, should recommend 6.x-2.0-beta1
* Latest version: 6.x-1.3-beta1

D) betas for both V1 and V2:
- existing: 6.x-2.0, 6.x-2.0-beta1, 6.x-1.3-beta1, 6.x-1.2, 6.x-1.1
- recommended major: 2
- supported majors: 2, 1
- current: 6.x-1.2
* Latest version: 6.x-1.3-beta1
* Recommended version: 6.x-2.0

E) mix of betas and stable releases for maintainers' recommended major:
- existing: 6.x-2.1-beta1, 6.x-2.0, 6.x-2.0-beta1, 6.x-1.2, 6.x-1.1
- recommended major: 2
- supported majors: 2, 1
- current: 6.x-1.2
* Recommended version: 6.x-2.0
* Latest version: 6.x-1.3-beta1

F) 3 major branches:
- existing: 6.x-3.0-beta1, 6.x-2.1-beta1, 6.x-2.0, 6.x-2.0-beta1, 6.x-1.2, 6.x-1.1
- recommended major: 2
- supported majors: 3, 2, 1
- current: 6.x-1.2
* Recommended version: 6.x-2.0
* Also available: 6.x-3.0-beta1

G) Simple case, out of date: [TODO: broken]
- existing: 6.x-2.0, 6.x-1.2, 6.x-1.1
- recommended major: 2
- supported majors: 2, 1
- current: 6.x-1.1
* Recommended version: 6.x-1.2 // Evil, prints 2 things as "Recommended"
* Recommended version: 6.x-2.0

The solution to (C) is pretty easy, it just means we need to be a little more complicated about if there are only releases with "extra" in their version strings from the recommended branch, that we recommend the most recent release. Note: this is a case that in general should never happen with responsible maintainers, but in practice, it'll happen in contrib.

(G) is more tricky to solve, especially without breaking the string freeze. :( I see the following choices:

G.1) Break the freeze, and in this case, use different labels like "Recommended current release:" vs. "Maintainer's recommended release:".

G.2) Leave it like it is in the patch with 2 "Recommended" versions. This is confusing and lame.

G.3) Leave it like it is in the code right now, and call 6.x-2.0 "Also available" in this case, and leave 6.x-1.2 as "Recommended".

G.4) Call 6.x-1.2 "Also available" and keep 6.x-2.0 as "Recommended" in this case.

G.5) Call 6.x-1.2 the "Latest" release in this case, and keep 6.x-2.0 as "Recommended".

Any opinions on these 5 options for case (G) would be most welcome.

Thanks,
-Derek

p.s. Note: because this is touching the same code, and since I was working on it on the plane home, this patch includes the same fix to the comment I submitted separately over at http://drupal.org/node/210140

that'd still break the string freeze, and it also seems more confusing than G1.

@alexanderpas: it doesn't work like that now, nor would it with my proposed change. We never recommend releases with "extra" (e.g. -alpha, -rc, etc) over official releases without extra. At most we list those as "Also available:". But the fact that we list 6.x-2.1-alpha2 as "Also available" is a good example to illustrate why if the 6.x-2.* series is now recommended by the project maintainer, and a site is running 6.x-1.2, we shouldn't just say: "Also available: 6.x-2.0", it'd be better to tell the site owners that "6.x-2.0" is actually recommended.

@gabor: We wouldn't mark their current release as a warning or error, but if the maintainer has said that "6.x-2.*" is the recommended branch, and a site is currently up to date with the latest 6.x-1.* release, it'd be better if update.module told the site owner that their release is supported and current, but the maintainer is recommending this other version now. Yes, it might break APIs, etc, but the maintainer has now decided the newer version is recommended (and therefore, presumably stable), which is the first step towards dropping support for the older branch entirely (when update.module marks your version as an error and screams you should upgrade ASAP). During that transition period, it'd be nice to give site owners some warning that they're not current with the maintainer's recommended version, and they should start to consider an upgrade. If it just says "Also available: 6.x-2.3" you have no way to know it's not just "Also available", but also "Maintainer recommended".

Heh, whoops. I just searched for issues assigned to myself and found this. ;) Not actively working on it anymore, so un-assigning. ;)

Kinda 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 (the title of which is whack, and it's really about showing the latest release from all later major versions of a given project)...