Description of problem: The Target milestones select field is not sorted correctly. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Search for a Bug in beaker 2. Look at the Target Milestones after refreshing them 3. Actual results: 0.10 comes before 0.6.1 etc etc Expected results: 0.10 should be at the end Additional info:
Are they not sorted ascending by default? If so, it looks like a bug in the algorithm that thinks that 0.10.0 < 0.6.0
(In reply to comment #2) > Are they not sorted ascending by default? > > If so, it looks like a bug in the algorithm that thinks that 0.10.0 < 0.6.0 Assuming the sort key is the same, they are sorted as a string by default (which explains why 0.10 < 0.6) -- simon
OK. Surely the _intent_ is to sort by ascending versions though yeah? (at least for those strings that represent numbers, I realise there are some strings in there like 'future_maint' etc)
(In reply to comment #4) > OK. Surely the _intent_ is to sort by ascending versions though yeah? > (at least for those strings that represent numbers, I realise there are some > strings in there like 'future_maint' etc) Nice to have, but MySQL doesn't support natural sorting, so I cannot see it happening. We have a sortkey on the table which is the correct solution around it.
Right, you would have to do it in bugzilla. Other apps can do it. So manually sorting for every set of target milestones where it's not done correctly is the correct solution? At least close it WONTFIX, rather than NOTABUG, as it clearly is a bug.