make it possible to not have *any* branch recommended

I think we will need something like this or something even better, because I have no idea how an unstable release will look like on the project page, and how can I tell that it is unstable..
#311949-33: Provide us with core developer releases

This belongs in the project issue queue, since this feature would be useful to sites other than drupal.org as well.

Right, if this is going to happen at all, it needs to happen in project_release.module. However, it's sort of a can of worms...

a) We need to closely look at the update_status client code to make sure it's not going to freak out in some unexpected way if there's no recommended major version. I *think* I wrote in code to try to do the best it can if there's nothing specified, but we need to be very sure.

b) The project maintainer UI at node/N/edit/releases needs to change so it's not just a set of radio buttons to select the recommended version (or we add a "nothing recommended" option to that table).

c) The JS that helps that UI needs to be changed accordingly.

d) We need to then go through the rest of the code and ensure that we're not assuming there's always a recommended version. Currently 83 occurrences of "recommended" in project_release.module. :/

So, this is no small task, and it seems like we've got a lot of more urgent things to attend to. If anyone wants to start running with this, please feel free, but I can't in good conscience commit to spending time on this myself in the short term.

question: do we need an option to mark more than one branch (for the same Drupal version) as recommended?

based on #313090-41: Change all contrib module's "Recommended" labels to something else?

@Pasqualle #4: Good question, but the answer is 'no'.

If you have multiple stable branches that you're still supporting, you still have to chose one and only one that you "recommend". There are two reasons for this:

a) When browsing projects, you only get a single download link for what new users should be grabbing for each version of core. If you filter that page by your core version, all you see is a "Download" link, in fact. We don't take up the space to present all the various options in those project browsing teasers.

b) Update status needs to only have a single release that it calls "Recommended" so as not to overwhelm site admins with too many choices. Besides, all of update_status (and update.module in core) is written to assume there's one and only one recommended version for any given version of core, and that's basically impossible to change until D7. I don't think we'd even want to change it in D7.

makred http://drupal.org/node/447360 as duplicate

That is, unless someone else wants it. ;)

I believe this might do it. It seems to work pretty good. Granted, there are alot of use cases for project that I just can't test on my own.

@JoshuaRogers: Thanks for taking a stab at this. From a *very* brief skim of the patch, it looks like it addresses 3.b (though, I'd love a screenshot of what the new UI looks like). However, the prerequisite task is 3.a. I definitely can't commit anything like this if update_status is going to flip out without a recommended branch. That's really the first thing that has to happen in here. The actual UI changes are a relatively small part of this issue, compared to all of the things I listed in #3 that need to happen to make this possible.

So, do you want to start looking at update.module in D6 core and searching for places that refer to "recommended" and see what you can come up with? You can test it by pointing your D6 test site to a different update status XML server (at least for a specific test project or something), and put your own XML file there where you remove mention of recommended, etc. See http://drupal.org/node/210984 for full details on how to do this.

Thanks!
-Derek

3a: From reading through the update status module, I do not believe there should be any problem. Everytime it used the recommended version in the module, it always had a backup plan in case it none was listed. Usually if there was not a recommended version listed it would fall back to choosing the most recent official release.

3b&3c: Done. The checkboxes (as seen in the attached screenshot) act like radio buttons (with the help of js.)

3d: I actually looked at project_release. I had to make a change or two, but in general almost nothing seemed to freak out if there was no recommended version. Because of the use case where there is no supported version, it seems that the use case where there is no recommended version was already built into the code.

I've looked at it several times now. It seems that if no recommended version is available, it will try to use the most recent release. I can't find any problems with it.

Thanks, that's good news. Note: I've got a ton of things going, and I can't always drop other things to work on whatever other people find itchy at the moment. ;) So, I'll just take your word for it that this is viable, and assume it's worth continuing to spend energy in this thread...

Next would be project-release-create-history.php and make sure it doesn't print out <recommended_major> if there isn't one. Oh, look at that, that's how I wrote it in the first place. ;) Yay...

Ok, assuming everything else is working, my concern is back to the UI itself. Checkboxes that behave like radios with the help of JS sounds potentially confusing and annoying, and I don't know how it degrades. I don't see any additional validation in the PHP part of the patch that ensures there's at most 1 recommended branch. I think users will see checkboxes and want to mark multiple things recommended, the JS will prevent that, and they'll think it's a "weird bug", not intended behavior. If you have N things and you can select only 1, radios are the natural UI that everyone expects. If they see radios, the immediately know they can only get 1. The problem with the radios is that once you select something, it's hard/impossible to select "none", unless you add a whole other row to the table just for saying there's no recommended branch.

This UI sounds a lot like the UI issues we faced over at #423304: Add a per-project default component setting to simplify the UI when submitting issues. Based on the outcome of that, the most natural UI might be to remove the radios entirely, and add a separate drop-down selector for the recommended version, which would include a "none" option. It might be slightly tricky to enable/disable choices in that drop-down based on which branches are marked as supported, but I guess it really shouldn't be much harder than what it's doing now to enable/disable radio choices.

Meanwhile, while you work on the UI, I'll see if I can make time to put this on d6.d.o, configure a few projects without recommended versions, and then we should see if we can get some folks to really pound on update.module and see if they can find any problems...

Thanks for moving this forward!
-Derek

On the http://drupal.org/project/modules page which release will be displayed? Does it have the same fallback plan (as update_status) when there is no recommended release?

@dww: I'll try to start working on the drop down this evening.

@pasqualle: If there is no recommended release, it behaves just as it would if there is no supported release: It shows the project information but no information about releases. Personally, I think that it seems like a reasonable thing to do.

@JoshuaRogers: Brilliant. The help text needs to be slightly tweaked, but otherwise, that looks great. We barely need any JS for this at all, in fact. ;) Just to (en|dis)able the "show dev snapshot" checkbox and the element in the drop-down for each (un)supported branch. Well, yeah, I guess that's still a fair bit. And the "hey, you changed something, don't forget to save" highlighting would be nice to keep in some form. Anyway, keep up the great work. Thanks!

The only minor snag with the screenshot in #15 is that I'm afraid that gives users the impression that they have to select a specific release as "currently recommended". Not exactly sure how to word it best, but we want to make it clear they're selecting the recommended branch, and the "current release" is just a hint to clarify. Maybe something like:

"Recommended major version:"

with options that look like:

3 (currently: 6.x-3.0-alpha)
2 (currently: 6.x-2.4)
1 (currently: 6.x-1.8)

? Maybe too clumsy. Maybe it'll look ok once it's implemented, I'm not sure. But, something to clarify that the setting is for selecting a major version, not a specific release. I haven't pondered the possible solutions much, but I just wanted to raise the issue...

How does this look? Since we're refering to each major release and now the most recent release for each major, I kind of think that we might not really need to put that the recommended for 6.x major 1 is 6.x-1.0-dev (or whatever it happens to be for a project.) I believe refraining from putting it should clean up the UI a very little bit, and lower the required number of db queries.

Patch described / shown in #18.

Well, the reason we added that "current recommended" in the first place was to help prevent confusion about what the "major version" actually means, etc. It was helpful to give people a sense of "given these settings, what would I see on the project page".

Perhaps a better approach to that is a "live preview" of what the project page release table would look like. ;) Maybe that's overkill.

That seems like it would be a whole lot more coding. This might not be as appealing, but have a look at the attached screenshot. I'm hoping that it solves the issue of the confusion, without needing for most of the UI to be redesigned.

Once again...
My Goal: Learn to update statuses in the issue queue before D7 comes out.