The attached patch fix some inconsistancies versionator -> version_is_at_least() function. Added two extra functions (needed for version_is_at_least): - versionator_sub_level_to_num() - versionator_sub_num_to_level() a small addition to __versionator__test_version_is_at_least(), the following two rows: version_is_at_least "1.0.0" "1.0.0_alpha" && echo "test 24 failed" version_is_at_least "1.0.0" "1.0.1_alpha20050101" || echo "test 25 failed"
Created attachment 54785 [details, diff] versionator.eclass.patch
Created attachment 54786 [details, diff] versionator.eclass.patch braindead, the previous patch was done on a versionator.eclass.old already modified ( __versionator__test_version_is_at_least() ) this should be the right one.
mmmh still one thing: in versionator_sub_level_to_num() "p" "Patch level" has lower priority than "r" "revision number", probably this should be inverted. At you the choiche
Might be a few days before I can get to this one, I'll need to go over it very carefully. Does it need committing in a hurry for anything in particular?
I agree with you that you need to threat it carefully. Now I use it for overlay of nightly build of MySQL 4.x,5.0, because it's an overlay I'll simply add a "my_versionator.eclass" for the time you need to check and accept/reject this patch. Short answer: keep the time you need, no Hurry here
ciaranm: bump, could you see about getting this into the tree? I'd like to put the new MySQL versions in this week, without having to hack around versionator.
Hrm, looking at this some more, I'm really not liking the way it handles things. I'll have a go at doing it the other way and see if it comes out any cleaner.
Created attachment 58630 [details] versionator.eclass Give this one a go. It may well be buggy...
Created attachment 58631 [details] versionator.eclass This one has a version_sort too just for the hell of it.
Created attachment 58642 [details] versionator.eclass Bugfix in sort...
Created attachment 58942 [details] versionator-testcase.tar.bz2 the attachment contain the following files: -ebuild_list.txt list of gentoo ebuilds (~18000 entries) -test_version_compare.txt result of the ~18000 comparison -test_versionator.php php implementation of the functions. -test_version_compare.sh wrapper to call the function from test_versionator.php -test_version_sort.sh wrapper to call the function from test_versionator.php -versionator.eclass you know The result of the test is correct here (x86 gnu/linux) . Some interesting examples are: 0j-r1 (cmp) 0.4 = 1 (less than) 1.0 (cmp) 1.0.0 = 2 (equal) 1.0-r1 (cmp) 1.0.0-r1 = 2 (equal) version_sort() has been only superficially tested, has you commented it's dangerous try to use it with more than few dozen of elements.
The 1.0 == 1.0.0 thing is intentional. I'm pretty sure 0j-r1 (cmp) 0.4 is correct too -- letters have lower precedence than the number part, so 0.0* comes before 0.4*.
I was sure it was, its needed also to compare a "real" version number versus a developer created one right? It's not so inituitive anyway, maybe a pair of line can be added to the docs or simply to the eclass comments?
I'd say that it's 'intuitive'. Consider the alternative... version_is_at_least 1.0.0 1.0 returning false would be kinda weird...
Ok, it's in the tree.
