GHOP #55: Make release summary table UI look more like update(_status)? report

My current belief is that we should have two flags:

1) a 'recommended' version. This isn't actually a flag, it's a field that's coupled with the API version. It's set via a checkbox on the edit release page or a button on the view release page 'make this the recommended version'.

2) An 'also list' which IS a flag on a version, and simply makes it listed on the front page.

This actually significantly reduces the complexity of the queries, I think.

subscribe

I need to ask for some clarifications on this task.

Merlin, could you elaborate on what you mean by:

This isn't actually a flag, it's a field that's coupled with the API version.

I don't understand what you mean by coupling it with API version. I would presume that all supported API versions should still be displayed on the releases page. This has the effect of multiplying what we see on the screenshot (update_status has the luxury of only checking one API version). Otherwise, we make users hunt down older APIs in the "All releases" page.

Let's suppose that we will display all supported API versions on the download page. Then, if we make a particular release recommended, there may/should be multiple recommended versions (one for each API version). Conflict resolution when multiple releases on a single API version (the reverse) have the recommended flag set could be punted to validation (which would check to make sure no other version is valid, or even un-mark that version) or simply have the latest version win.

One possibility is a project-wide, recommended branch (as in major.minor) designation. In fact, update_status does not appear to display the patch version! You would still have to specify multiple branches per API version, as a release version can only have one API version assigned to it, so 1.0 might be for 5.x, while 2.0 would be for 6.x.

Here are some of the autodetection SQL queries for retrieving the necessary versions: (pseudo-SQL, I've probably bungled some column names, and left out FROM)

• Recommended version: SELECT WHERE extra = '' WHERE major_version = '$major' SORT BY minor_version DESC SORT BY patch_version DESC LIMIT 1
• Latest version: SELECT WHERE major_version = '$major' SORT BY minor_version DESC SORT BY patch_version DESC LIMIT 1
• Also available: SELECT SORT BY major_version DESC SORT_BY minor_version DESC SORT BY patch_version DESC LIMIT 1

If we do decide to assign "recommended" or "see also" to specific releases, a usability issue manifests: a mass-edit release page (checkboxes for recommended / see also). Otherwise, performing mass-updates because extremely cumbersome, especially if ticking a new version recommended doesn't undo the old one. Fortunately, this may not be necessary due to the above-mentioned conflict resolution.

I still think, however, that the simplest way, code-wise and SQL-wise, is to mark releases as recommended or version (although it would need the form mentioned above for this to work well). Marking branches as recommended feels a little too black-magicky for me, and there's still a question of whether or not a branch is "major.minor" or just "major" (while Drupal fairly solidly uses "major", other projects may have different release patterns, PHP, for example!)

So... if you've read this whole thing, here are the primary concerns:

• Will multiple API versions still be displayed?
• Will recommended releases be auto-detected or specified (if specified, via a specific version, major version, or major.minor branch?)
• Will see also releases be auto-detected or specified (see above)?
• Will all recommended releases be displayed, or will there be some sort of conflict resolution?
• Should we implement a mass-edit page?
• And one last thing: Should we rename "see also" to "Cutting-edge release" or the like? (See also is terribly ambiguous)

Work cannot continue without satisfactory answers for these questions. Thank you!

Thanks! That clears things up. There is one more question:

Would the admin have to specify multiple recommended branches? This would be if the latest version 2.0 works with the 6.x API, but only 1.3 works with 5.x. If recommended was set only for "2.0", there wouldn't be any recommended branch for 5.x, so multiple recommendations would be necessary. (And that says nothing about what to do if no recommendation is made, perhaps just not include the recommendation field?).

I think the way to handle branches is to be flexible, and let the user use major or major.minor. The selection field would look something like:

• 1
  • 1.0
  • 1.1
  • 1.2
  • 1.3
• 2
  • 2.0
  • 2.1

Asking them whether or not major.minor or major is a branch seems needlessly complex. Of course, there would need to be conflict resolution if both 2.1 and 2 are specified as recommended.

So... should I leave this to you? I ask this because I decided to pick this up as part of Google's Highly Open Participation contest. As it stands, it sounds like fixing this bug directly would cause more harm than good. I'd be more than happy to help out, but I'm not exactly sure how. Please advise. :-)

Unassigning self.

I've made a note about this on the official GHOP task tracker. Hopefully we'll get someone to work on this soon!

One thing we might want to think about here is that we have a task submitted to the project to rip out our specialized file handling for project_release nodes and instead use core file upload handling. One benefit is that this could potentially allow us to have multiple files associated with one release node. For example, a windows, mac-intel, and mac-ppc version of a release (obviously such a use case would not apply to d.o, but this would be really useful on other sites).

I just brought up the issue at http://drupal.org/node/179471#comment-697699 of how the download table might change to accommodate multiple files in a release. Though there is not a need to worry about this much now, we might keep this in mind when redesigning the release table here, as there may be decisions we can make now that make work easier in the future, if we do decide to go this way.

Patch attached! This is so awesome! A screenshot is attached, too, in case you want to see what it looks like :D.

One comment about the screenshot -- You're marking the 1.x and 3.x official releases as "May be outdated" and "May be unstable". That's not necessarily true. All three branches may be stable, but provide different features or be substantially different "under the hood".

The maintainer recommends one branch as the "Most stable/supported" release and the others are simply "Also available".

Also - How does the patch deal with different core compatibility -- separate tables?

That as why I put it as "may be outdated" and "may be unstable" rather than "outdated" and "unstable." If you have a better idea, go ahead; it's just simple text, it can be altered quite easily, or even removed if deemed unnecessary/confusing/misleading.

I'm confused about what you mean here. The text on the page is determined by the settings (supported/recommended): Only supported versions are shown, and only the recommended one is highlighted in green. If it's the actual text you want to change, that's simple enough; but chances are that anything I do won't fit in with your picture of what the ui should look like.

"The corresponding strings from the update_status UI"... what does that even mean? Why would it be a good thing to show that?

If you could respond quickly, that would be helpful and extremely appreciated, as I have only about 12 hours left to finish this and claim a final task. Thanks!

-cwgordon7

- There's another text field on the project maintainer UI for these captions. We just print out the check_plain()'ed version of whatever they write. We should probably validate this field to be no more than 30 characters or something, so that people don't go crazy writing little essays in there which make the table look nuts.

I'm all for allowing project maintainers a small space to indicate something like this.

For now, following discussion with dww in irc, in order to keep this task in scope, I'm only addressing the table ui issues. There is a new patch attached.

Note: I'll likely continue to work on this even after this particular part is finished.

New patch

The current incarnation of this (at http://project.drupal.org/project/signup) looks much improved over the first version. I think there are still more ways it can be improved, but for the purposes of the GHOP task credit, I'm satisfied. Marking the Google task complete. Will leave this CNR.

Another bug:

If I look at the Schecule module on http://project.drupal.org/project/Modules/category/61 when I'm logged in but haven't selected a version to filter by, I get two releases shown:
HEAD (developer release with red X)
4.7.x-1.0 (supported release with yellow triangle)

However, if I click on the title and view the project's node, I get only one release:
4.7.x-1.0 (recommended release with green check)

So why is the same release supported in one place and recommended in another?

Also, is there any way to test out the changes to the project edit --> releases settings on p.d.o? On d.o I have access to edit all projects since I'm a site maintainer, but apparently those privs don't carry over onto p.d.o, and I have no projects of my own yet to look at.

Hm....I just looked at the projects overview page (same as link above) again and there are no more download tables at all. Strange.

@dww: Thanks for the privs.

@all: I might have found another bug, or maybe I'm not completely understanding how things are supposed to work here.

If I look at the releases settings for the project module at http://project.drupal.org/node/3281/edit/releases , and make the settings shown in the first screenshot, I get the release table at http://project.drupal.org/project/project (the project's summary page) shown in the second screenshot.

Why does the release table have options for 6.x when there are no releases for project module for 6.x? And why does it show two possible major versions?

And, this might be a separate discussion to have, but it seems like it would make more sense for the releases in the download table to be sorted opposite of how they are now being sorted. Shouldn't releases for 6.x come above those for 5.x? That's how it currently works on d.o.

I think this new patch should fix most, if not all, of the problems. Let me know.

-cwgordon7

This may not be stable. I think I've worked out most of the bugs, but I could be wrong. Here's at least a half-finished patch.

@dww: I was going to take a crack at reviewing/fixing this, but cwgordon7 said you told him you were going to rewrite parts of it. I don't want to duplicate work, so let me know if you've already rewritten this.

This patch fixes a problem in project_release_table().

Instead of:

  $orderby[] = 'r.version_major';
  $orderby[] = 'r.version_minor';
  $orderby[] = 'r.version_patch';
  $orderby[] = 'r.file_date';

  if ($orderby) {
    $order_by = ' ORDER BY '. implode(' DESC, ', $orderby);
  }

we actually want:

  $orderby[] = 'r.version_major DESC';
  $orderby[] = 'r.version_minor DESC';
  $orderby[] = 'r.version_patch DESC';
  $orderby[] = 'r.file_date DESC';

  if ($orderby) {
    $order_by = ' ORDER BY '. implode(', ', $orderby);
  }

The former way works except that the last element of the $orderby array, in this case r.file_date, does not get the DESC appended and so therefore is ordered in the wrong direction.

I'm setting this to CNR for now.

There are still some bugs here:

A.) If you click the "Show snapshot releases" box for a API version of a project with no snapshot releases, no releases (not even official) will be displayed in the download table.

B.) I'm still not getting a separate snapshot table like I think we want. I only get an Official releases table, even for a project with development snapshot releases. This is true even if I check the "Show snapshot releases" for an API version.

C.) For some of my releases/projects, I only see certain releases in the table if I check the "Show snapshot releases" box, even if the release itself is an official release and not a snapshot release.

D.) For some projects, I'm not able to get any releases to show up in the download table, regardless of the settings I make in the Release administration page.

I am clearing the cache using the devel clear caches link, so I don't believe any of these problems are due to caching.

Looks good to me. Tested on p.d.o and works as expected.

i really like it. the only thing i'd suggest is giving a little thought to the "Currently recommended:" coloring on the edit/releases page. you're using yellow to denote changed but it's the same shade as the warning text in the downloads table. i'd either leave it white or have it match the colors in the download table, e.g. selecting a branch with only a -dev release gives you a red background.