Version sorting is no longer correct with D10

Well, I'd say it is correct because the view sort works alphanumerically. Do you know if there is a view sort plugin for Drupal that allows sorting by semantic version numbers?

I found the PHP function "natsort", which could do the right pull, but I have no idea how to use it view plugin...

That module may be an option. You could give it a try by installing the other module and adjusting the view accordingly to see if that works.

Hey there,

Maintainer of Views Natural Sort here.

I'll be the first to admit that Views Natural Sort may be a bit heavy in it's current form for what you need as it is an all or nothing approach. Meaning it will index all fields and properties... and the field/property would have to be a limited text field and not a blob style field for it to work.

That said, limiting what fields get indexed isn't a small feat on it's own. It's on my todo list but people expect the module to turn on and "work" on every field when they add the view handler to the view, but the indexing part of the issue puts a damper on that. There are also cases to consider where you want different fields indexed differently like in the case of a version field like what you have here.

The nasort wasn't an option for libraries and the like for performance reasons. It's best if the database handles that... and the only way for the database to handle that most of the time is if you trick string sorting into doing it the way you want to.

For whole positive numbers there's 2 ways to handle this. the simple way is using left padding, adding the number of zeros you need to make the largest number you would want to handle. Example, if your versions number go up as far as 2 digits, you would need to pad every number up to 2 digits so that

9.1.1
10.1.1

becomes

09.01.01
10.01.01

Another way (the way Views Natural Sort handles it) is to story the number of digits in the number before the number so that all numbers that are in the same string position and have the same digit count will be sorted together. The below example works up to 9 digit numbers. Views natural Sort handles up to 99 digits using a combination of the first and this approach.

8.1.1
9.1.1
10.1.1
20.1.1
100.1.1

becomes

18.11.11
19.11.11
210.11.11
220.11.11
3100.11.11

That would be stored in the database... you sort by that special string, but display the original

Next, View natural Sort attempts to sort decimal numbers as well and I don't currently have a flag to turn that off. I could... that and negative numbers both... I'll add that as a feature request now

If yall are cool with having VNS as a dependency I can probably patch this... otherwise you can use Computed Field → (with or without the module) to make a hidden string that does what I described above.

thoughts?

If yall use table header sorting... yall may have to actually use Views Natural Sort to make it happen. I just recently solved that problem. It's hard to make a views field handler sort by a hidden field that is not the field you are "displaying"

I do have a couple of tricks to limit the number of items that need to be indexed and I actually have a plugin in my tests that handle "Chapter numbers" which turns out to be the same as version numbers. Let me give this a shot and see what yall think.

Thanks a lot @generalredneck for the detailed input on this and to offer your help, this is much appreciated.

However, we might be lucky and the DRD data model may help us resolving this without any extra tricks. The view is a list of release entities and the version field is a string. Those release entities have a reference to a major entity and that contains the coreversion field which is an integer containing 6, 7, 8, 9 or 10.

We should be able to add the relationship from release to major into the view and then sort by major.coreversion first and release.version second. That should give us the expected sorting at least for the first component which seems to be the main concern.

@steveoriol the screenshot you're showing in the OP doesn't seem to be a view from DRD but a custom one. Do you want to give this suggestion a try and let us know if that solves the issue for you?

@jurgenhass & @steveoriol,
You will still find it difficult if you are using table heading sorting on that field. I've not gotten my build of DRD to work enough to find out yet, but if it is, you may have to create a custom field handler for that field so that you can fill out how to make that work. see the code for Drupal\views\Plugin\views\field\FieldPluginBase.

Good point, we'll see if @steveoriol needs that in his use case and if a more sophisticated solution would even be worth the effort.

Thank you both for your help.

For the moment, this inconvenience is not a priority, DRD is still doing its job very well ;-)