| 1 |
On Sat, Sep 19, 2015 at 4:11 AM, Vladimir Smirnov <civil@g.o> wrote: |
| 2 |
> On Fri, 18 Sep 2015 23:16:43 +0800 |
| 3 |
> konsolebox <konsolebox@×××××.com> wrote: |
| 4 |
> |
| 5 |
>> If you avoid trying to adopt versioning practices which are far from |
| 6 |
>> practical and very far from common it is (as proven by the example |
| 7 |
>> code). The workaround for such rare cases should be done on the |
| 8 |
>> ebuild's version. |
| 9 |
>> |
| 10 |
> |
| 11 |
> Just have a look on CPAN module versions. You'll see that it's much more common than you think. Just few examples: |
| 12 |
> http://search.cpan.org/~pip/Math-BaseCnv-1.6.A6FGHKE/ |
| 13 |
> http://cpansearch.perl.org/src/MMCLERIC/Ubic-1.58_01-TRIAL/ |
| 14 |
> |
| 15 |
> And so on. There are much more than that. Also strange version translations, where new release may just start to use new version scheme. And so on, and so on. |
| 16 |
|
| 17 |
And the ambiguous part of the current spec which interprets numbers |
| 18 |
starting with 0 differently didn't really help much in solving |
| 19 |
problems in adapting those irregular versioning schemes. |
| 20 |
|
| 21 |
That is why it's better to just implement a more simple and consistent |
| 22 |
universal approach and keep the decisions on how those irregular |
| 23 |
versions should be represented in ebuilds to the ebuild maintainers. |
| 24 |
|
| 25 |
As for A6FGHKE and TRIAL, it's impossible to tell their actual level |
| 26 |
values so even if we choose to map them lexicographically, we would |
| 27 |
still not be able to use a universal algorithm that could tell how it |
| 28 |
affects the base version (just like how stages affects it) and how it |
| 29 |
compares with other values as well. So it would still be up to the |
| 30 |
maintainer how he would represent the versions on ebuilds. |
| 31 |
|
| 32 |
One could do: |
| 33 |
|
| 34 |
Math-BaseCnv-1.6.20YYMMDD |
| 35 |
|
| 36 |
and |
| 37 |
|
| 38 |
Ubic-1.58.01.20YYMMDD or Ubic-1.58.01_pre20YYMMDD |
Archives