Sort version lists with version_compare()

Sadly, version_compare() won't help us. However, there's a lot of logic and functionality in Project* for properly sorting complex version strings. Sadly, that logic isn't yet used consistently (it's all been a work-in-progress). See the big @TODO comment above project_release_get_releases() in project_release.module.

What we really need is to remove project_release_get_releases() entirely, and probably further refactor project_release_query_releases_by_branch() into something like project_release_query_releases() that lets you either filter or sort by branch. You still have to define the project id. But, if you leave the $api_tid or $major as NULL, it adds the corresponding DB column to the ORDER BY, not the WHERE (or something like that -- not sure exactly what the most intuitive API would be).

There is same problem in translation interface in localize.drupal.org (l10n_server module). See #790722: Version order in translation form is confusing.

@Salvis Nice, this sorting function seems promising! I used similar approach, but with my own version parser. Usage of version_compare is (at least) undoubtly faster.

Confirmed, quite annoying.

+++ project_release.module	10 Apr 2010 19:25:13 -0000
@@ -717,9 +717,24 @@
+  if ($a == $b) {
+    return 0;
+  }

We can test $a == $b prior to string replacements already.

Aside from that, this patch makes sense and is badly needed. Not sure whether it fixes all locations where versions are listed though.

--
That said, doesn't natsort() cut it already...?!

# php -r "$a = array('6.x-1.9', '6.x-1.x-dev', '6.x-1.11'); natsort($a); var_dump($a);"

array(3) {
  [0]=>
  string(7) "6.x-1.9"
  [2]=>
  string(8) "6.x-1.11"
  [1]=>
  string(11) "6.x-1.x-dev"
}

As I already mentioned in #2, I can't actually test this because I don't have any project data/installation.

http://drupal.org/project/drupalorg_testing

;)

@salvis: There's no giant team of "someone" who works in the Project* issue queues testing things. There are 2 maintainers, 1 amazing contributor (right now) and an very tiny group of other people who help out at various times. We're all extremely busy. The whole point of this distro is to make it really trivial to have a useful test site so you don't have an excuse not to test your work. ;) You download a single tarball, unpack it in a webroot, visit install.php and you're done. I hope that's not too much to ask...

Does this also affect the version select list on issue comment forms, as visible on this very page?

Subscribing. I'll try to test the patch in the next few days.

Salvis's proposed algorithm was commited to the Localize server project so this code has being tested at localize.drupal.org for year now... #790722-6: Version order in translation form is confusing

Patch still applies and works flawlessly. Tested on a local environment with a plethora of version numbers, different API, major, minor, patch, and extra data; everything sorts perfectly. This would be a huge boost to accurate bug reports on drupal.org. I get at *least* 10 reports a week that are improperly filed in the queue because the latest version number is muddled somewhere in the middle of the list. With Drupal core having minor releases exceeding 25, I imagine misfiling is common in the core queue as well.

re: #9 @salvis: natsort() discards keys? That's odd, because the var_dump() in #4 exposes that the array key associations are retained.

> php -r "$a = array('a' => '6.x-1.9', 'z' => '6.x-1.x-dev', 'e' => '6.x-1.11'); natsort($a); var_dump($a);"
array(3) {
  ["a"]=>
  string(7) "6.x-1.9"
  ["e"]=>
  string(8) "6.x-1.11"
  ["z"]=>
  string(11) "6.x-1.x-dev"
}

> php -r "$a = array(619 => '6.x-1.9', 61 => '6.x-1.x-dev', 6111 => '6.x-1.11'); natsort($a); var_dump($a);"
array(3) {
  [619]=>
  string(7) "6.x-1.9"
  [6111]=>
  string(8) "6.x-1.11"
  [61]=>
  string(11) "6.x-1.x-dev"
}

array_reverse($versions, TRUE);

@see http://php.net/manual/en/function.array-reverse.php

Thanks!

Sorry for the delay here folks. ;) Life's been crazy. Anyway, we had a similar (only worse) bug in the D7 port, so I just resurrected this patch. Sadly, natsort() is confused by -beta1 and friends. So, we really did want #9, not #20. Committed and pushed to 6.x-1.x and 7.x-2.x branches. Already deployed on the D7 staging site: http://git7site.devdrupal.org/project/issues/views. Tagged it for live d.o deployment, that'll happen soonish.

Thanks!
-Derek

The next weekly drupal.org push-to-prd will happen this coming Thursday Oct 25th at 1:00pm PDT. If all is well, it could go out then. See the drupal.org calendar at https://drupal.org/website-schedule

Deployed.