| 1 |
On Thu, 3 Nov 2016 17:11:22 +0100 |
| 2 |
Michał Górny <mgorny@g.o> wrote: |
| 3 |
|
| 4 |
> 1. Revision number must be no longer than 9999: |
| 5 |
> 1a. to make <=X-r9999 reliable, |
| 6 |
> 1b. to prevent pathological uses of revision as date. |
| 7 |
|
| 8 |
I think most the arguments you've made for this stem from subjective |
| 9 |
and social problems, not technical ones. |
| 10 |
|
| 11 |
I'd hate to be artificially limiting the utility of what can be done |
| 12 |
with "-r" versions just because *some* of those versions *may* be |
| 13 |
confusing for humans. |
| 14 |
|
| 15 |
I could just as easily argue that using -r200 and -r300 is "confusing", |
| 16 |
and that 1.2r-300 "could be a problem" and maybe we should abolish |
| 17 |
-r'vs entirely. |
| 18 |
|
| 19 |
The -r200 and -r300 were also not just arbitrary numbers, but they |
| 20 |
followed the slot version, and so the "-r" suffix was itself not purely |
| 21 |
a "X < Y", but also conveyed data about what it was for, and served as |
| 22 |
a predictable anti-collision mechanism ( due to the whole |
| 23 |
2-slots-cant-have-identical-versions deal ) |
| 24 |
|
| 25 |
And as you know I was considering a similar strategy to be able to have |
| 26 |
several variations of the same perl virtual for upgrade reasons, but |
| 27 |
that would predictably have a much wider variety of '-r ' prefixes to |
| 28 |
represent the wider variety of significant Perl versions. |
| 29 |
|
| 30 |
|
| 31 |
|
| 32 |
> 2. I think we could use a policy to make >=X_alpha reliable. However, |
| 33 |
> I have no clue how to word it without making it weird and artificially |
| 34 |
> restricting valid version numbers. |
Archives