"Downloads" portlet shows *older* version than current stable

[Thierry Carrez]

On a project page (for example https://launchpad.net/nova) the "Downloads" portlet supposedly shows the latest version available. However, if you have:

Essex series: Current stable release, with 2012.1 milestone released in Apr, 2012
Diablo series: Supported, with 2011.3 milestone released in Sep, 2011
Cactus series: Obsolete, with 2011.2 milestone released in Apr, 2011

Then the "Latest version" shown on the main page is Diablo's 2011.3 !
You have to mark Diablo series "obsolete" to get Essex's 2012.1 milestone shows as the latest version.

Launchpad should show as "latest version" the latest version (current stable release), certainly not an old supported version.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Thierry Carrez (ttx)]

This is not a duplicate of bug #419733. Bug 419733 says you should show latest stable in addition to latest. I'm saying that when you have a recent "current stable" and an old "supported", showing the old "supported" as latest is plain wrong.

i.e with
C under development
B current stable
A supported

Launchpad currently shows "A" as latest. Bug 419733 says "you should show B in addition to C". This bug says "you should show B rather than A".

[Soren Hansen (soren)]

Sorry for flogging a (seemingly) dead horse here, but while I do agree this bug falls under the "it's not completely clear which version to show in the \"Latest download\" portlet" problem umbrella, I think this particular bug is quite clear: If there's a "Current stable" release and a "Supported" release, I think it's unambiguously clear that the one marked "current stable" is to be preferred over the "Supported" one.

Even if it weren't clear, I don't see why "supported" should take precedence over "current stable" (which is apparently the case right now). At the very least, they should be counted as equal and then "latest download" could be determined based on either release date or version number.

[Francis J. Lacoste (flacoste)]

I agree that this is a more narrow problem. Nonetheless, anyone attempting a fix to this bug should consider bug #419733 and its many duplicates to assess the acceptability of the fix.