from project_release_query_releases_by_branch():
// Within releases of the same version_extra_weight (e.g. rc1 vs. rc2) just
// sort alphabetically, so that rc2 shows up first in the query.
$order_bys[] = 'r.version_extra DESC';
this doesn't work in all cases, unfortunately -- as beta10 ends up being less than beta9... :(
the views handlers look like they suffer from this same bug.
nobody makes that many extra releases, you say? unfortunately that's not the case...
http://drupal.org/node/647814
this looks like a particularly bad problem with three possible solutions:
- leave it, because it won't affect many people -- they shouldn't be making double-digit extra releases anyways ;)
- do PHP stuff on the version extra string
- move the entire sorting process to the version_extra_weight field, and make the version_extra field just for display.
#1 is probably a bit irresponsible ;)
#2 defeats the purpose of moving making the version_extra_weight field in the first place :(
#3 three will involve a fairly major refactor, plus a db update that could be tricky. :(
no fun at all. option 3 or something like it is probably what should happen i think.
Comments
Comment #1
hunmonk commentedComment #2
dwwYup, that's a bug alright. Fairly nasty one, in fact. I'm on it. I'll ponder and research a bit. One quick idea:
4. Add a version_extra_delta field (or something -- "version_extra_iteration", "version_extra_number"?), and if version extra contains a number, we stick it in there when the release node is created. Then we sort on version_extra_weight and version_extra_delta.
But yeah, we need to fix this...
Comment #3
dwwWell, if we do #4 from comment #2 (this is why I like to order options in issues with letters, not numbers, btw), project_release_update_N() going to be pretty nasty:
We're going to have to load each of those 15310 records from {prn} into RAM, do a little preg_match() on version_extra, then issue separate UPDATE queries for each one. Definitely going to want batch API for this...
I don't really know of a better way to solve this than #4 at this point, and I got Earl to look and he agrees. I think I'll just start coding that and see how nasty it gets. I'm slightly worried about assuming a specific format of version_extra, but, i guess if the regexp is something like
.*(\d+).*it should be pretty safe. if there's a number in there, use it. I guess the actual regexp could be another non-UI setting in settings.php if someone really needed a different one on their own project_release install for some reason. ;)Comment #4
dmitrig01 commentedsort by nid or created time :P
Comment #5
dww@dmitrig01: see #642096: Provide a better mechanism for sorting releases with version_extra defined: introduce version_extra_weight
Comment #6
pasquallesame problem with imagecache-2.0-beta10
also what happens with feedapi 1.8 vs 1.9-beta3. As I know before the views integration the 1.9-beta3 was the recommended now the 1.8 is..
this change will affect the sort in the usage statistics table also, right?
Comment #7
kmontysubscribe
Comment #8
kmontyAlso, is there a way that we can downgrade to the previous packaging code? Managing the issue queue is becoming a major hassle because everyone is using outdated software
Comment #9
pasqualleDon't panic! the packaging and the update status works correctly, so the users will see a nice red error message when they are using the wrong version. This is just a small UI bug on d.o, nothing more..
Comment #10
dwwRe: #6: "same problem with imagecache-2.0-beta10"
That's exactly the release mentioned in the original report. ;)
Re: #6: "also what happens with feedapi 1.8 vs 1.9-beta3. As I know before the views integration the 1.9-beta3 was the recommended now the 1.8 is.."
That's a feature, not a bug. See #647428: Show latest prerelease (if different from recommended release) with dev releases
Re: #8: "Also, is there a way that we can downgrade to the previous packaging code?"
It's not a packaging thing at all. It's strictly the UI on d.o project pages in this edge case. Anyway, this is near the top of my list for today, hopefully I'll have something working and deployed this afternoon.
Cheers,
-Derek
Comment #11
rfaySubscribing. Amazon module has this problem.
Comment #12
kmontyBump. This bug really needs to be fixed. There is really no way to revert to the old 'simple UI' code until the latest version is patched?
Comment #13
pasqualleThere is always a way to revert, but in this case that would be more work than fixing this issue..
Comment #14
rfayYes, this is important. I did an RC1 release as a workaround, but this is an overall bad situation to be in.
Comment #15
dwwI've had a ton of fires to deal with the last month, and haven't been able to get back to this. Yes, it's a bummer, but it's not like children are dying because of this bug. The code is all sitting there in CVS if anyone really wants to fix it. ;) I've already explained what the most likely solution to fixing this would be -- it's not like I'm the only person on Earth capable of understanding this and solving it.
That said, I might have a chance to get to this at some point over the next week, although I desperately need a vacation and a break, so I'm not going to make any promises...
Cheers,
-Derek
Comment #16
dwwtagging -- we can't ship 6.x-1.0 without fixing this
Comment #17
bdragon commentedTaking a shot at this.
Comment #18
bdragon commentedOK, done and seemingly working.
One thing I am unsure of is whether we should continue to do
$order_bys[] = 'r.version_extra DESC';in project_release_query_releases_by_branch().In this patch, it is left out. I can re-test later with it in, but I don't have time at the moment to do that, so I'm submitting the patch "as tested" instead of doing another run locally.
If it were to be in, I guess the correct order would be to have it after the
$order_bys[] = 'r.version_extra_delta DESC';.Lastly, here is what the code came up with for deltas.
Thoughts?
Comment #19
bdragon commentedWhoops, my comment broke something. Probably the query result I posted at the end.
-----
OK, done and seemingly working.
One thing I am unsure of is whether we should continue to do
$order_bys[] = 'r.version_extra DESC';in project_release_query_releases_by_branch().In this patch, it is left out. I can re-test later with it in, but I don't have time at the moment to do that, so I'm submitting the patch "as tested" instead of doing another run locally.
If it were to be in, I guess the correct order would be to have it after the
$order_bys[] = 'r.version_extra_delta DESC';.Comment #20
dwwTemporarily blocked on #699528: project_release_compute_update_status() can't move a release from not secure to current. Here's an updated patch that cleans up + clarifies some comments, and also restores the ORDER BY as suggested by bdragon in #19. Attaching the interdiff from #18, too.
Comment #21
dwwNow that #699528: project_release_compute_update_status() can't move a release from not secure to current is done, re-tested on d6.p.d.o, committed to HEAD, merged into d.o SVN, deployed on d.o, and ran the db update (with a little drupalorg_form_alter() hack to disable add/edit on project and release nodes while it ran -- silly to take the whole site offline for this). Things are looking sane now:
http://drupal.org/project/imagecache
http://drupal.org/project/feeds
http://drupal.org/node/647814
Yay! Thanks again bdragon for getting this most of the way there...
Comment #22
dwwOh, whoops. We forgot something: #700018: Expose {project_release_nodes}.version_extra_delta to views ;)