Change all contrib module's "Recommended" labels to something else?

I've griped about this to aclight in #irc before, but never came up with anything good as a replacement. I reckon 'Latest stable release' is pretty good though - since that's what it is.

sorry, crossposted.

yes, that seems much better than "recommended" in terms of accurate information.

As discussed on IRC: We are declaring "development snapshots" as dangerous. While *we* see those snapshots as releases (we know the inner workings), end-users do not. Hence, any release (visually) above those development snapshots tends to be stable or whatever. Labeling BETAs and RCs as "stable" does not work for me. If at all, those would be "official".

However, simply replacing "Recommended for ..." with "Latest release for ..." would work.

Q: Patch for drupalorg or project_release ?

What if a developer wants to "recommend" a previous stable release though? I don't necessarily see a constant link between 'latest stable' and 'developer recommended'. I like the terminology now, but I can understand how it could be misleading. Perhaps the wording to be changed to 'Maintainer recommended' or add simply a disclaimer under the releases saying 'This module is not endorsed by Drupal.org' or something like that?

Switching information back to what it was before I messed it up.

I'm -1 on changing "Recommended" to "Latest release" for a few reasons:
1. It might not be true. A maintainer could create a new official release from a relatively new branch (DRUPAL-6--2-0-BETA1, for example), which might or might not be more recent than a DRUPAL-6--1-5 tag. If the maintainer marked the DRUPAL-6--2 branch as supported, and the DRUPAL-6--1 branch as recommended, then any tags based on the DRUPAL-6--1 branch would be marked as the "Latest release" even if there was a more recent release from the DRUPAL-6--2 branch. Granted, it might still be the latest release for a specific tag, but I think this will get even more confusing for end users because the date of the release is displayed on the download table, and if the dates don't match with the "Latest release" indicator then people will get confused.

2. The update_status module uses "Recommended version", not "Latest release". Since that's in core, it's unlikely to change.

According to the handbook page at http://drupal.org/node/197584:

Once again, unless you have very good reason for doing so, do not release beta/rc/extra versions as recommended and NEVER release alpha versions as recommended.

The current functionality is, IMO, fine for the most common practice, which is to create a new branch of a module, create alphas, betas, etc., and then release. After that point, any changes to that branch should ideally be bug fixes or minor improvements. New APIs, large changes, etc. should go into new branches. Maintainers should mark branches in alpha/beta as supported (if they are) until a final release is ready, at which time the branch can be marked as recommended.

The one use case that the current functionality does not support is something like what is used for Views. For example, Views 1 is only 1 branch for Drupal 5.x. Earl often creates alpha/betas/RCs for minor increments in the version number, eg. DRUPAL-5--1-5-BETA1, DRUPAL-5--1-5-RC1, DRUPAL-5--1-5 (I made those tags up, so they may not actually exist). In this style of naming, the DRUPAL-5 branch would have to be marked as recommended, and that means that whenever a new beta/RC is created, that node will be marked as the recommended version for that branch. This isn't ideal, but you can't really write the system to automatically work with both conventions, and since core follows the first one I assume that's why project_release does the same.

I think the best solution to this problem is to finish #230793: Link from "Recommended for 6.x", "Development snapshot", etc. in release table to explanation, which should make it more obvious to users what "Recommended", "Supported", and "Development snapshot" mean.

@Senpai: no, that is wrong again

you could have many supported versions for the same Drupal release, but only one could be recommended
check: http://drupal.org/project/ecommerce

"Recommended" and "Supported" have different meanings. Please do not mix them.

However, that brings up a completely different, but closely tied point: The label "Supported for 6.x" equally implies that "drupal.org supports this release".

@sun: Do you have any evidence that people are often making the mistake and thinking that because the download table says "Recommended" or "Supported" this means that someone other than the project's developer(s) is making the recommendation or providing the support? I find it hard to believe that there are too many people who are that clueless.

I've never had a problem with the current implementation of "recommended" or "supported."

To me, "recommended" with the checkmark icon simply means that that's the one you want to use for your version. "Supported" with the yield/exclamation icon means use with caution.

Never have I thought that Drupal.org officially supported them. Nor have I seen posts in the forum with users thinking that.

And on the front page of modules (http://drupal.org/project/Modules) it says: "Contributed modules are not part of Drupal core releases and may or may not have optimized code/functionality. " Maybe add some text to that explaining the differences in releases (or provide a link to some documentation.)

@silverwing: Panels for D6. I can hardly pretend that it's "Recommended" right now; even 'Supported' would be kind of a stretch. Yeah, it says alpha, which definitely helps, but...bottom line, if I want to provide anything except -dev snapshots (and I do, because I'll never be able/willing to guarantee that -dev is always stable), then it's gotta be 'Recommended.'

@aclight: Yes, when D6 was just out I was talking to someone who looked at a module page and saw "Recommended for 6.x" and said to me "Oh, and it's even recommended!" To which I had to reply "Er, no, that just means that is the version you should use." "Oh. Well that's silly."

True story.

I'm +1 on changing "Recommended" to something more descriptive, because "Recommended" is not.

a) "Latest release" won't fly, since that's wrong in the general case.

b) This functionality is fundamentally about what the maintainer thinks of their branches. For all the branches for a given version of core, the maintainer can specify which ones are still maintained/supported/viable, and of all of those, which one (and only one) does the maintainer think most people should use. I'm obvious biased, since I wrote all this crap in the first place, but it seems like "supported" means "the maintainer still thinks this can work" and "recommended" means "the maintainer thinks you should use this one". If we're going to change this terminology, we need to pick new terminology that reflects what it's representing.

c) One of the other goals of this stuff was to automate as much as possible -- meaning that it'd be evil and error prone if maintainers had to constantly update which release shows up in the download tables. The idea is that they should only have to tweak that stuff around the time they're creating new branches, not after every official release.

d) I'll admit that things are weird as you're first porting to a new version of core. If all you have is an alpha release, that's the "recommended" version for 6.x, because it's the *only* version for 6.x. :( I'm not 100% sure what to do about this, other than make it possible to not have *any* branch recommended -- and just mark 6.x as "supported" until there's a 6.x-1.0 official release at which point the maintainer can mark 6.x-1.* as "recommended".

e) All of this terminology came originally from update_status and update.module (now in core). If a maintainer marks a branch as no longer supported, and you're using that branch, your update_status client will put a big warning next to that project saying "Unsupported release". Similarly, if you're running 6.x-1.0 and 6.x-2.0 is out and the maintainer marked 6.x-2.* as the recommended branch, then the update_status client says: "Recommended version: 6.x-2.0". It seems even more confusing if the terminology in core disagrees with the terminology in use on the project pages. Thanks to the string freeze in stable releases, it's impossible to change the D6 update.module now, so the best we can do is introduce new terminology in D7's update.module and try to make it not too terribly confusing on the project pages. Concrete suggestions about how this is all supposed to work would be necessary before I was comfortable changing the project pages.

So, if this is going to change, we need:
- Concrete proposal for what the existing terminology is going to be replaced with.
- Discussion about the confusion factor if update.module and project nodes are using different terminology.

The only thing I can think of doing that wouldn't completely suck but would help the D6 panels case sdboyer raised would be making it possible for maintainers to leave no branch recommended (point (d) above). Then, for example, if you filter the project browsing pages or 6.x and there's no maintainer-recommended version available, the project wouldn't even show up (as if there was no release for that version of core at all). And, on the project nodes, the 6.x-1.0-alpha1 release should just be marked as "supported" with a yellow row and the little warning icon.

If people think that's worth doing, we should open a new issue specifically about that in the project issue queue. I'm not totally convinced it's worth the effort (or delaying D6 porting efforts), but I'm open to a discussion about it.

@dww, there's quite a difference between having a module installed on your site, and update status nudging you to upgrade it, compared to checking out a project page for the first time. For a start you're recommending one version of a module over another, which isn't clear on project pages when only one might be displayed. I think the context is different enough that having inconsistent wording might not make much difference (I've never thought about them being the same at all).

How about changing it from "Recommended for X.x" to "Recommended version" for now? That would get rid of my personal gripes about the wording which at least some people share. Then we could look at the technical issue of having no recommended versions at all later on.

There seem to be three different but related arguments going on here, and the solution to one won't address the other.

Argument 1:
The original argument brought up by Senpai is that by using the terms "Recommended" and "Supported", we are implying (or some users might think we are saying) that drupal.org, the amorphous organization that it is, is recommending a certain module or a certain branch of that module. Alternately, drupal.org will be supporting a certain version or branch of a module. People making this argument would probably say that if a user was on, say, acquia.com, and saw the same thing, that would make sense, since that's what Acquia does. But the fact that this is d.o, and there is no real "recommendation" or "support" is confusing to end users.

My response to this is that I think it's pretty unlikely (and Crell's comment #15 above doesn't necessairly rebut this feeling, because the module *is* recommended by the maintainer). However, to address this argument we have to move away from using the words "Recommended" and "Supported", and in fact need to not use a verb at all to describe the release. Thus, Senpai's suggestion of an adjective/noun combination, "Latest stable release". I've commented above on why I think that's a bad idea, so I won't rehash it here.

Argument 2:
Some people seem to be talking about how "Supported for 6.x" is confusing on its own, regardless of who is doing the supporting. I can see how people really new to the community might get confused about this, if they aren't at all familiar with our version numbers, etc. In comment #9 Senpai suggested "Supported for Drupal 6", which IMO is a bit more clear to newbies that this particular version of a module should be used with Drupal 6.

Argument 3:
The ability of maintainers to specify "Supported" and "Recommended" releases is sub-optimal. There are use cases that the current behavior of the project_release module does not support, as I pointed out in comment #8 and sdboyer pointed out in #14. dww made a suggestion in #16d that would address one of these use cases, but as he says there that should be a separate issue, and may or may not be worth fixing right now, given the drive to get the D6 port of project* finished.

Since discussion of argument 3 doesn't belong here, I think we need to decide which of argument 1 or 2 (or both) is actually a problem. It'd be nice to have more than anecdotal evidence here, but that's probably all we'll be able to get. My opinion is that we should leave the phrasing as is is right now (or possibly change "Recommended for 6.x" to "Recommended for Drupal 6", etc.) and create or modify a handbook page that explains what this text means in sufficient detail that anyone who reads it won't be confused any longer. If people are confused, and there is a link on the text that confuses them, but they don't click on it, well, I guess they will still be confused. This approach is described in #230793: Link from "Recommended for 6.x", "Development snapshot", etc. in release table to explanation.

If we end up changing this text, I think it needs to be as a patch to the drupal.org module, and not to project_release itself. The issue I just linked to has the relevant code that would need to be changed, in case someone wants to create a patch that does something different than what my not-quite-a-patch in that issue would do.

#16d moved to #313827: make it possible to not have *any* branch recommended

Because "recommended" and "supported" aren't "just fancy ways of saying 'Doth Worketh With'", precisely because "latest" is not always "best to use for a real site". Maybe 5.x-2.* is an experimental branch for adding a bunch of new features. 5.x-1.2 might be 6 months old, but it's still the "recommended" release for people using this module since it's stable and works great. 5.x-2.5 might have been released yesterday, yet it's full of mostly untested new features that worked on the developer's machine, but might eat your kittens if you put it on your production server. Currently, that's expressed by:

5.x-2.5 -- supported for 5.x [yellow, with the warning icon]
5.x-1.2 -- recommended for 5.x [green, with the checkmark]

If you were looking at this table trying to decide which one to use, even if you didn't bother to read the release notes you'd probably make the right choice. However, what about with your proposal:

5.x-2.5 -- works with Drupal 5 [green, with the checkmark]
5.x-1.2 -- works with Drupal 5 [green, with the checkmark]

Overwhelmingly, unless people read the release notes (unlikely), people are going to grab the first one, to the detriment of kittens everywhere. No thanks. ;)

The more I think about this issue, the more convinced I am that "Supported" and "Recommended" are the right words for this. If the root of the "problem" here is that we suspect some users are confused about who's doing the supporting and recommending, then it seems all we need is to somehow make it clear we're talking about ...by the maintainer(s) of this project. A few options:

A) The label for that table column is currently just "Status". Maybe that should be "Maintainer's chosen status" or something.

B) Actually cram that into the labels in the table itself, something like "Maintainer recommended for 5.x".

Of course, then people will be confused by which "maintainer" we're talking about. *sigh* We could say "The maintainers of this [project type] recommend using this version for Drupal 5", but then the table will be way too wide on most screens. That's why I like #230793: Link from "Recommended for 6.x", "Development snapshot", etc. in release table to explanation -- let's just give some contextual help text for these things and link to a page that clearly spells out what these little labels actually mean. I don't see any good way to make fully self-documenting labels in that table that doesn't cause it to grow into something entirely unwieldy and clumsy.

as I see now, the issue #230793: Link from "Recommended for 6.x", "Development snapshot", etc. in release table to explanation is quite critical :)

and also, the documentation http://drupal.org/handbook/cvs/releases/types needs a little update

notes like:
supported does not necessarily means stable. if it is an alpha or beta release, then it is not stable..
Recommended does not mean "this module is great!"..
Supported does not mean "drupal.org supports this release"..

@senpai: How about reading what I've already said? ;)
#313827: make it possible to not have *any* branch recommended
In cases where the *only* release for a version of core is alpha/beta (or even rc), it'd be nice to let the maintainer not specify that anything is actually "recommended" yet. Sadly, it's a big can of worms, since such a chance has potentially far-reaching implications. Meet us in the other issue if you have something helpful to contribute there. Thanks.

Not to bicker, but yes, it does address exactly what you're talking about. You want the *only* release for a version of core to say something other than "recommended". I'm not saying it's not marked with anything, I'm saying it's marked with a yellow "supported" and a warning icon, instead of a green "recommended" and a check mark. I know you think you're just talking about a "simple" wording change, but it really is a functional change to Project* (and potentially update_status, which is why it's a can of worms).

I do get why we can't say "Latest stable" and I also get why we need the distinction between "Recommended" and "Supported" and to what they're referring. But, fwiw, I have also seen one or two flame-wars erupt on IRC because someone used a crappy module that they said was "Recommended" to them by the Drupal website, as well as the fact that they couldn't get "Support" in #drupal when the module says it's "Supported." And had a discussion similar to Crell's at a Lullabot workshop once. So I do think this is worth fixing.

Here's my proposal:
- BOTH of them say "For use with X.x". Colors and icons are used to differentiate recommended from supported. The internal keys that Update Status module uses could stay the same.
- Additionally, the release configuration table @ node/X/edit/releases gets a new column with a select box for "Version Description" with options like Stable, Testing, Legacy. This would default to Stable.

This is what it would look like:

@webchick: Yay! That mostly rocks. :) A few (minor) concerns:

a) You really don't mind that the update(_status)? UI says stuff like "Recommended version: 5.x-3.5" but when you land on the project page, there's no mention of "recommended" anywhere?

b) What if a maintainer has 3 branches, 5.x-3.*, 5.x-2.* and 5.x-1.* -- 5.x-2.* and 5.x-1.* are both "stable" (bugfix-only), and 5.x-3.* is "unstable" (new feature development). Only one of them can be recommended? Wouldn't it potentially be confusing that you have two things listed as "For use with 5.x (stable)" and only one of them is green/checked? I guess this is much less common than the originally reported confusion in here (which seems to come up periodically), so it's not worth holding up progress over. But, I'd be curious to hear your thoughts.

c) Don't we need an option in that dropdown you propose like "Unstable" (or is that what you mean with "Testing")? I don't want to bikeshed too much in here, but it seems like these extra labels need to be carefully chosen. I don't think "testing" always correctly conveys what we need to get across for the "newer supported but not recommended" branches. It's not necessarily "testing" -- you might need one of the latest features for a production site, but, you're willing to accept the risk that other new features might introduce bugs, so it's not as "stable" as an older branch. Anyway, we don't have to completely decide on these words before we can start making progress on this -- obviously we'll have to have a site-specific setting for what these options should be, so we can always tweak this later as we come up with better (and perhaps more) options.

Thanks for breaking the log jam in here by understanding all sides of the debate and providing a great mockup!

p.s. One minor nit with your image: the 4.7.x row would be green since it's the only release for 4.7.x, so, internally, it'd still be "recommended", which means green. Either that row needs to be green, or it should be from the 5.x-2.* branch...

I like the mockup a lot. I'd probably go for 'testing' as well - you need to 'test' alpha/beta releases of modules before you run them on your production site (etc. etc.) Debian also has stable -> testing -> unstable - so if the -dev releases are unstable, then 'new but not quite ready yet' falls nicely into 'testing'. I reckon some people who have really long alpha/beta/rc releases for their modules might be happier with 'testing' compared to 'unstable' since it defines the approach the user should take to the code rather than being a comment on the quality of the code itself, but then I'm not one of those people.

Either way, good work!

a) I would not be concerned about update(_status), because the terminology makes more sense there, since a user has installed a module already. We can alter those strings later on, if we really need to.

b) As long as there is only one release per major version of module displayed, multiple branches for the same Drupal core version can be stable at the same time. IMHO, end-users are able to see the different major version numbers and can decide on their own. (There is, however, another issue in that "Release notes" always points to the specific release node, say 5.x-3.5, and maintainers do not have a way to describe 5.x-3.x in general for all minor releases. IIRC, there was an issue somewhere (in OG's queue?) about this.)

c) Yes, I'd agree that there is another state between "development snapshot" and "testing", particularly regarding unstable (D7), alpha, and beta releases. However, let's discuss this in #drupal first, since this issue is cluttered already.

@webchick: Plain awesome simplicity! :)

Alternately, what about this mockup below. I think it improves on webchicks mockup in the following ways:
1. Stable (recommended) releases are all on top, always. This decreases confusion for newbies who don't want to read or understand the different tables.
2. Not shown in screenshot: If there are no releases of a given type (stable, or testing/unstable), then instead of printing the row we'd print something like "There are no stable releases of this project." or something like that.
3. The "Stable releases", "Testing/unstable releases" table headers would link to handbook pages that give more detail about what that means. Alternately, instead of making the text itself a link, we might have a little question mark icon like what is used in the advanced help module that is the link. Note that someone with a bit more css wizardry could probably make sure that the first column in each table is the same width, so they don't look out of alignment like they do in my mockup.

Disadvantages:
1. In the project_release module it might be more difficult to handle the kind of data that might be necessary to produce such a table, though probably no worse than what would be necessary in webchick's mockup.

@dww:

the 4.7.x row would be green

no, only the stable release should be green

@webchick:
the mockup is missing one important point: the recommended flag
update_status have to know which stable release is recommended, when it could show a message to update to the recommended version.. recommended marked with [★] (star symbol)

and we should change the order. in most cases the user should grab the topmost release.

--------------------------------
Official releases:
--------------------------------
Stable:
6.x-3.5 For use with Drupal 6 (Stable) [★]
5.x-2.4 For use with Drupal 5 (Stable) [★]
5.x-3.5 For use with Drupal 5 (Stable) [✔]
Other:
6.x-4.0-alpha11 For use with Drupal 6 (Alpha) [!]
4.7.x-2.2 For use with Drupal 4.7 (Legacy) [!]

--------------------------------
Development releases (do NOT use in production):
--------------------------------
7.x-1.x-unstable-3 For use with Drupal 7 (Unstable) [✖]
7.x-1.x-dev For use with Drupal 7 (Snapshot) [✖]
6.x-4.x-dev For use with Drupal 6 (Snapshot) [✖]
6.x-3.x-dev For use with Drupal 6 (Snapshot) [✖]
5.x-3.x-dev For use with Drupal 5 (Snapshot) [✖]
5.x-2.x-dev For use with Drupal 5 (Snapshot) [✖]

As I see there is no need for a select box for "Version Description". The description could be automatically generated from the version and CVS tag.

@aclight: That looks great.

Re #32.2: "If there are no releases of a given type (stable, or testing/unstable), then instead of printing the row we'd print something like "There are no stable releases of this project." or something like that." -- I think we'd only want that for stable releases. If a developer doesn't chose to release testing/unstable releases (or none of them are current -- e.g. no one cares about 6.x-1.0-beta2 if 6.x-1.1 is already out), I'd think we should just leave out that table entirely. Ditto dev snapshots. But yeah, a lack of official/stable releases is worthy of a warning.

@Pasqualle #33 "no, only the stable release should be green" My comment was based on webchick's claim that: "Colors and icons are used to differentiate recommended from supported." -- Given that none of these mockups assume #313827: make it possible to not have *any* branch recommended, the details of my nitpick are all true.

In terms of your mockup, I don't think the star vs. checkmark is the right visual distinction, because a) the * tends to mean "required" in most of the Drupal UI, and b) I think the check is more visually prominent than a star, so it draws my attention to that row, which isn't the intended outcome.

@Pasqualle #34: I think you're still missing the point that 5.x-3.5 might be an official release from an unstable branch where new features are being added all the time. Sure, we can automatically say (as update_status does) that any release with "extra" version elements (beta, alpha, rc, etc) are inherently less stable, and if the only releases for a given branch have extra, we can mark that branch as "unstable". But, how do you distinguish between 5.x-3.5 is the latest official release from the unstable new feature branch vs. 5.x-3.5 is the latest official release from the stable bugfix-only branch? Please reread #29.b.

While we're on the topic of edge cases we should be able to handle, what about the release procedure that Earl tends to use for views? 5.x-1.5 was out, then 5.x-1.6-beta1, eventually 5.x-1.6-beta6, and finally 5.x-1.6 itself. So, while 5.x-1.6-beta3 was out, what should these mockups look like? Clearly, 5.x-1.5 should still be the recommended release. Update_status would say: "Also available: 5.x-1.6-beta3" -- how do we express that on the project nodes? Just put it in the unstable/testing table for the 5.x-1.* series row?

Note: while we're rehashing all this stuff, we should be sure to pay attention to #176776-41: GHOP #55: Make release summary table UI look more like update(_status)? report while we do it.

p.s. Whoops, marked #284762: Change "Recommended for 5.x" to something like "Made for Drupal 5.x" duplicate -- even though it's older, this issue has much more discussion and possible solutions in it.

For the views 1.6beta case, I'd say "just put it in the unstable/testing table for the 5.x-1.* series row" - can't think of a particular reason why that would be bad.

re: views 5.x-1.6beta -- sure, but then when 5.x-1.6 is out, the last unstable should go away, right? As a co-author of update_status, I just want to point out how hairy these heuristics and algorithms become. :/ My main fear is putting too much code into project_release that's really specific to the particulars of the d.o version number scheme. Maybe aclight and I can agree that "extra" always means unstable, but this might get thorny.

re @dww #37:

why not create a new term for project_release nodes called Release type or something, with options of "Stable", "Unstable/testing", and "Snapshot", or some variation of those.

For official releases, the maintainer would have the option of choosing either stable or unstable/testing. Development snapshots would not be changeable.

Then, to build the stable table, for each branch you take the most recently created release node of that branch with the "Stable" term (or maybe largest version number instead of most recently created), and do the same for unstable/testing.

This would introduce a new reason to make the taxonomy module required (I think it might already be required), but i'm personally fine with that. I think this would also make stuff a bit easier in the D6 port (if this goes in to the D5 version) because Views can handle terms on nodes natively and there will be less logic we would need to introduce to views handlers ourselves.

There might be a very obvious reason not to do this, but I can't think of one at the moment.

Wow, this thread got long while I was busy elsewhere.

Regarding the mockups (in #28 & #32) (this may be a nitpick, but it's what I try to do when communicating contrib versions), I think it would be better if the Status column added the word "Drupal" to the "For use with" phrase, as Pasqualle does in #33. I think that adds a little more disambiguation to the version numbers, especially for people who are new to all this.

@dww #29.a: she did say, "The internal keys that Update Status module uses could stay the same.", which to me means that no change would be necessary internally (at least in that aspect), but the UI could change to match d.o. Not having looked at the code, I have no idea if that's good or bad.

re #29.b. How can I tell that I have two stable bugfix-only branches for D5 (2 recommended branches for D5)? my answer would be, to don't do that. just simply drop the oldest release (meaning: always recommend the latest stable bugfix-only branch)..

which could look like:
5.x-2.4 For use with Drupal 5 (Stable) [★]
5.x-3.5 For use with Drupal 5 (Stable) [✔]
5.x-1.4 For use with Drupal 5 (Stable) [✔]

I don't really care about the symbols used. If the check mark would be a better fit for recommended, then find something for the "stable, not recommended"..
---

my recap:
I think the current functionality is perfect.
Webchick (#28) suggested a new feature (but that could be automatized, because it is only a descriptive word for the version numer+cvs tag)
Yes, extra always means unstable. (extra: alpha, beta, rc, unstable). And also, if there is no extra, that must mean stable. No taxonomy for this please..
---

(absolutely off topic) side note: the unstable tag could be used as #311949: Provide us with core developer releases if the module has the same patch rolling problem as core, or would like to provide a testing version for the latest D7-unstable..

@Pasqualle: What you are proposing here would unnecessarily limit and bloat the project release system. It is perfectly valid to have multiple stable branches compatible to one Drupal core version. Based on your example: if an end-user has 5.x-2.3 installed, she might not want to upgrade to 5.x-3.5, because a different major version indicates major (API) changes in the module, and thus requiring an extended module upgrade process including enhanced testing of an existing Drupal site. Hence, 5.x-2.4 is the latest stable release, recommended/supported by the maintainer to update to for this major version and core compatibility. Just like everyone knows that Firefox 3.x is better than 2.x, there is absolutely no need to mark a previous major version as deprecated when it is still stable and usable; also no need to force users to upgrade. As dww already pointed out, only one version can be recommended by the maintainer currently (thus colored green), until #313827: make it possible to not have *any* branch recommended is fixed. If a maintainer decides that a certain version is no longer supported, it would not show up in this list; also leading to bugging notifications from update(_status) module.

To summarize: this issue focuses on

- change the terminology in the Status column to "For use with Drupal #.x", just keeping the row coloring and icons for visual expression of "recommended/supported".
- eventually turn the official release table into one containing "stable releases" only, and an optional one containing "testing/new/focused releases" only.

...by altering the theme output of project_release in drupalorg.module.

btw: huh? There's a Drupal.org infrastructure "Drupal.org module" component AND a separate queue for "Drupal.org customizations" module?

dww directed me here from http://drupal.org/node/284762
So as I missed the discussion here with the mockups it has already come to a great point I only want to point out another reason why "Recommended" can be missleading: "Recommended for 6.x" could mean "Best to use with Drupal 6 - will work with other Versions as well".

@sun:

What you are proposing here would unnecessarily limit and bloat the project release system.

I am not really sure which part of my post you are referencing here. As I know I just described the current situation, I do not want to propose any functional change in this issue..
As I know update_status always ask you to upgrade to the recommended version, it does not care about that you will change a major version of your module. So your Firefox example is not really valid here.. (The only "exception" where update_status will not tell you to switch to a new major version is the Drupal core.)

@all: Sorry if I'm coming across like an obstructionist here. I don't want to make this harder than necessary, it's just a very thorny, complicated subject. As I'm fond of quoting Einstein: "Everything should be as simple as possible, but no simpler."

@aclight #38: We already have a taxonomy vocab for release nodes called "Release type" -- it's where you specify "New features", "Bug fixes" and/or "Security update". The problem is that folks don't know what to do with this, aren't careful about selecting them correctly, and we already need this #210497: add extra validation to release node form for security update releases. Furthermore, making the system even more explicitly reliant on that means more manual effort on the part of maintainers rolling releases, and makes the whole thing more error prone. I'd much rather find other ways to automate this then ask the maintainers to keep making the right choices in that vocab selector for *every* release. :(

@sun #41: re: two issue queues for d.o customizations -- it's just legacy that the infra queue has a component called this. It's from back when there was no drupalorg.module and we had a handful of projects that only ran on d.o that didn't have their own project nodes.

@Pasqualle #43: Sorry, but that's not actually how update_status works in the edge case we're talking about. ;) Here's an imaginary current state for 3 branches of the "foo" module:

5.x-3.2 is out (new features) [supported]
5.x-2.4 is out (stable) [supported + recommended]
5.x-1.6 is out (stable) [supported]

If you run 5.x-3.2, update status is all green and says:

foo 5.x-3.2: Up to date
Recommended: 5.x-2.4

If you run 5.x-2.4, update status is all green and says:

foo 5.x-2.4: Up to date
Also available: 5.x-3.2

If you run 5.x-1.6, update status is still all green, and says:

foo 5.x-1.6: Up to date
Recommended: 5.x-2.4
Also available: 5.x-3.2

So long as 5.x-1.* is still marked as supported, update_status does NOT nag you to upgrade, even if 5.x-2.* is recommended. It just lets you know you're not running the maintainer's recommended version for new downloads, as an early warning you might want to upgrade. Only if the maintainer marks 5.x-1.* unsupported will update_status start nagging you.

Therefore, what sun is saying to you in #41 is absolutely correct. However, I'm not sure we're going to be able to fix this just at the theme layer for d.o, since I believe we're really going to need a few (hopefully small and limited in scope) functional changes to project_release to really make this as easy as possible for project maintainers.

Phew... Sorry this is so complicated, and thanks for everyone being patient and respectful in here.

thanks dww, I knew that update_status is smarter than me

@aclight #38: We already have a taxonomy vocab for release nodes called "Release type" -- it's where you specify "New features", "Bug fixes" and/or "Security update". The problem is that folks don't know what to do with this, aren't careful about selecting them correctly, and we already need this #210497: add extra validation to release node form for security update releases. Furthermore, making the system even more explicitly reliant on that means more manual effort on the part of maintainers rolling releases, and makes the whole thing more error prone. I'd much rather find other ways to automate this then ask the maintainers to keep making the right choices in that vocab selector for *every* release. :(

So we call it "Release status" or something like that. The name isn't really important.

I think comparing a "Stable" vs. "Unstable/testing" term to the problems we have with the security term is not very useful. We have problems with the security term because it's not at all clear that by selecting the security term your release will not be published until the security team does so. It often seems like it's not even common knowledge that maintainers should report security problems instead of just fixing them themselves and creating a new release.

By having a term that maintainers can select, I don't think we're putting any real added burden on them. If you're speaking of an upgrade path thing, I imagine we can figure out something smart. But to support the various use cases that people want, I think we should just give slightly more control to project maintainers, instead of trying to hard code certain behaviors into project_release. Plus, "Stable" or "Unstable/testing" are pretty explanatory.

In addition, we don't allow maintainers to change any of the version fields once they've created them. So if we use the extra field to determine whether a release goes into the stable table or the unstable table, I anticipate that we'll get a bunch of support requests from people that maybe want their release to go into the other table for some reason.

If we wanted to we could even pick the appropriate term automatically, and not even reveal the term widget to maintainers. That could be a d.o specific customization, or maybe part of the project_release module itself.

Basically, I think it makes more sense to use terms to separate releases than it does to have a field in the db to do it.

@aclight #46: Webchick was talking about a new field that applies to branches/major release series, not individual releases. Just like you can currently specify supported/unsupported per branch, and can select a single recommended major version/branch per "API compatibility term" (to use the internal project* terminology for that vocab). This seems relatively easy for maintainers to get right, and avoids problems of making the release node form more complicated (and therefore, error prone).

In terms of the comparison with the "Security update" term -- true, there are bigger problems there. All I mean is that folks are already pretty sloppy selecting those terms, and I'd rather not make the system any more reliant on that then it already is.

Basically, I think it makes more sense to use terms to separate releases than it does to have a field in the db to do it. At some level, that's very hard to argue with. ;) However, the problem is that I'm basically talking about branches, not specific releases, and branches aren't (always) nodes, so you can't have taxo terms on branches.

@dww: Yeah, good point. My comment was originally addressing #37, about how to handle the Views situation, but you're right that terms on branches isn't going to work, since they aren't nodes.

One thing about this whole idea of Stable/Unstable and Testing/Development Snapshot tables--how does recommended fit into all of this? It's entirely possible that a module might have two stable branches, yet the maintainer would like to recommend one of them, but have both show up in the download table. But if we make green represent stable releases but not necessarily recommended releases, how do we indicate which branch a maintainer recommends?

Closing old issues. Marking this as closed as it appears to be addressed. Please re-open if needed.