| 1 |
>>>>> On Fri, 4 Nov 2016, Kent Fredric wrote: |
| 2 |
|
| 3 |
>> 1. Revision number must be no longer than 9999: |
| 4 |
>> 1a. to make <=X-r9999 reliable, |
| 5 |
>> 1b. to prevent pathological uses of revision as date. |
| 6 |
|
| 7 |
> I think most the arguments you've made for this stem from subjective |
| 8 |
> and social problems, not technical ones. |
| 9 |
|
| 10 |
Exactly. That's why this is not intended for PMS but for the |
| 11 |
devmanual. Developer time is one of our most valuable resources. |
| 12 |
|
| 13 |
> I'd hate to be artificially limiting the utility of what can be done |
| 14 |
> with "-r" versions just because *some* of those versions *may* be |
| 15 |
> confusing for humans. |
| 16 |
|
| 17 |
> I could just as easily argue that using -r200 and -r300 is |
| 18 |
> "confusing", and that 1.2r-300 "could be a problem" and maybe we |
| 19 |
> should abolish -r'vs entirely. |
| 20 |
|
| 21 |
> The -r200 and -r300 were also not just arbitrary numbers, but they |
| 22 |
> followed the slot version, and so the "-r" suffix was itself not |
| 23 |
> purely a "X < Y", but also conveyed data about what it was for, and |
| 24 |
> served as a predictable anti-collision mechanism ( due to the whole |
| 25 |
> 2-slots-cant-have-identical-versions deal ) |
| 26 |
|
| 27 |
I think nobody is arguing against using r200 etc. for special |
| 28 |
purposes. |
| 29 |
|
| 30 |
> And as you know I was considering a similar strategy to be able |
| 31 |
> to have several variations of the same perl virtual for upgrade |
| 32 |
> reasons, but that would predictably have a much wider variety of |
| 33 |
> '-r ' prefixes to represent the wider variety of significant Perl |
| 34 |
> versions. |
| 35 |
|
| 36 |
I would assume 9999 to be high enough, even if you use multiples of |
| 37 |
100 to label the slot. Or do you expect having more than 100 slots for |
| 38 |
Perl? |
| 39 |
|
| 40 |
Ulrich |
Archives