| 1 |
Joe Peterson wrote: |
| 2 |
|
| 3 |
> Ciaran McCreesh wrote: |
| 4 |
>>> 3. "Extend versioning rules in an EAPI - for example, addition of the |
| 5 |
>>> scm suffix - GLEP54 [1] or allowing more sensible version formats like |
| 6 |
>>> 1-rc1, 1-alpha etc. to match upstream more closely." |
| 7 |
>>> Apart from GLEP54, I believe our versioning scheme works reasonably |
| 8 |
>>> well. I don't see any need to match upstream more closely. I'd rather |
| 9 |
>>> like to keep the more uniform way of handling suffixes like rc and |
| 10 |
>>> alpha, that we have now. |
| 11 |
>> |
| 12 |
>> Please explain why 1.2_rc3 is legal but 1.2-rc3 is not. |
| 13 |
> |
| 14 |
> I actually like the current format in that it does *not* allow "-" in |
| 15 |
> the version. For example, pkg-2.3.1_rc5 makes it clear that the string |
| 16 |
> from "2" to "rc5" is the version. If were were to allow pkg-2.3.1-rc5, |
| 17 |
> this could get visually confusing (looks a bit like pkg-2.3.1-r5). In |
| 18 |
> this case, *less* flexibility and more strict rules serve a good |
| 19 |
> purpose, I think. |
| 20 |
> |
| 21 |
Agreed; the purpose of an internal format specification is not to allow |
| 22 |
NN variants on a theme all over the place. It should nail things |
| 23 |
down to ONE variant which everybody can collaborate around. |
| 24 |
|
| 25 |
I missed the clamour of developers complaining about this oh-so-burdensome |
| 26 |
restriction that they've been dealing with for at least 5 years. Until I see |
| 27 |
that happening independently of this current hooha, I'm going to consider |
| 28 |
this 'reason' to be yaf "straw man". |
| 29 |
|
| 30 |
-- |
| 31 |
#friendly-coders -- We're friendly but we're not /that/ friendly ;-) |
Archives