make it possible to not have *any* branch recommended

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.

@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

@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

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

@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...

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.

Ugh, just ran smack into this wall rolling the first alpha release of Drupal 7.... :(

We had to resort to a ghetto workaround of putting the links to download the alpha/dev snapshot in the project page at http://drupal.org/project/drupal.

I don't suppose there's anyone around here who'd have time to dive in and fix this in relatively short order? :P

Ugh. Well, marking the D7 branch unsupported meant that Update status told everyone:

"Project not supported: This project is no longer supported, and is no longer available for download. Disabling everything included by this project is strongly recommended!"

;)

For now (ultra quick hack, I'm out the door), I hacked the release history XML on updates.d.o to replace this:

<project_status>unsupported</project_status>

with this:

<recommended_major>7</recommended_major>
<supported_majors>7</supported_majors>
<default_major>7</default_major>
<project_status>published</project_status>

so at least Update manager doesn't freak out when people install alpha1. :(

However, that's going to be clobbered on the next cron run, so it's only a very stop-gap measure.

We should probably just fix the UI bug here on the project node, so that we can correctly mark this branch as supported.

If anyone wants to try testing #21, see if it even still applies, etc, that'd be great!

Another temp hack so this change isn't clobbered while I'm AFK... I just added the attached patch to project-release-create-history.php on d.o...

Unsurprisingly, patch #21 doesn't apply anymore. However, with a combo of sneakiness and rerolling, I got this working again. I also fixed a few problems in the UI (e.g. using "Recommended major version" instead of "Recommended Branch"). I've installed it on http://d6.project.drupal.org and it seems to be working nicely. I made a fake 7.0-alpha1 core release there, and I'm attaching screenshots of both the project page (http://d6.project.drupal.org/project/drupal) and the admin UI (http://d6.project.drupal.org/node/3060/edit/releases). I'm also showing some of how it looks for a contrib with multiple branches.

The only reason this needs work now is that the help text at the top of this page is all wrong. ;) I should really double check some of the code in project_release_get_current_recommended() and project_release_check_supported_versions() to make sure nothing is going to explode with this change, but so far, limited testing on d6.p.d.o looks good.

Fixed the help text. Before:

For each term in the Core compatibility vocabulary, the following tables allow you to define which major versions are supported. If there are releases from more than one major version number, you can select which major version should be recommended for new users to download. You can also control if the development snapshot releases should be displayed on the front page of the project. Finally, for each term in the Core compatibility vocabulary, the current recommended release is shown. If no official releases have been made, the development snapshot from the corresponding branch will be listed. Otherwise, the most recent official release will be listed.

With this patch:

For each term in the Core compatibility vocabulary, the following tables allow you to define which major versions are supported. You can also control if the development snapshot releases should be displayed on the front page of the project. Finally, for each term in the Core compatibility vocabulary, you can select which major version (if any) should be recommended for new users to download.

See screenshots from d6.p.d.o...

Still need to look at project_release_get_current_recommended() and project_release_check_supported_versions() more closely, but we're getting real close now.

btw, see also #686918: Add help text to project release admin page to warn about marking branches unsupported and the impact on update status

Results from reviewing project_release_check_supported_versions(). Everything looks great, except this:

      if ($num_branches == 0) {
        // First entry for this API tid. Add it as supported and recommended.   
        $recommended_branch = 1;
      }

if we're in the processing of adding a new release, and it's the first release for a given version of core ("API compatibility term"), we add a record to {project_release_supported_versions} that's marked as supported and recommended by default. Project admins can always go in and mark the branch not recommended if they like. Perhaps it should default to supported + not recommended at first, and the project admin has to manually go in and mark it recommended when they see fit. Chances are that the very first release for a new version of core is going to be an alpha/beta or something, and probably not going to want it to show up as "recommended" right away. And, at least it'll show up as an "Other release" immediately, so they won't necessarily freak out and submit critical bug reports about "I made a new release but it doesn't show up on my project node, we should stop using CVS!". ;) Anyway, input on this default behavior would be most welcome.

project_release_compute_update_status() looks great. It doesn't care if the branch it's checking is recommended or not -- it's just dealing with per-branch status and logic. So, that's also fine.

project_release_get_current_recommended() is also fine. If you call it with a specific major version, it uses that, regardless of if that major is recommended or not. If you don't, it just returns NULL if there are no recommended releases, and call sites already have to be able to handle that. Plus, it looks like the only call site that currently still exists always specifies a major version. ;)

So, we're basically set, other than the question above about defaulting new branches to be supported but not recommended...

In IRC, stephthegeek said:

stephthegeek: dww, i don't do a whole lot of actual project maintenance but i like the idea of it being supported first rather than recommended, for exactly the reasons you say

Here's a patch for this. Tested heavily on d6.p.d.o. I think this is ready...

I don't think I'm going to find any more real reviews for this, and I've tested it well, so I committed to HEAD. Just need to deploy on d.o now, stay tuned.

Deployed:

http://drupal.org/project/drupal

WOOHOO! Awesome. Thank you so much, dww, for fixing this and rolling it out in such a hurry. Hugely appreciated.