[Sugar-devel] Proposal of dotted activity version number

[Gonzalo Odiard]

On Mon, Oct 4, 2010 at 1:37 PM, Jonas Smedegaard <dr at jones.dk> wrote:

> On Mon, Oct 04, 2010 at 12:50:37PM -0300, Gonzalo Odiard wrote:
>
>> Short version:  Gogogo!
>>
>> Thanks!
>>
>>
>>  Slightly longer: Make sure to strictly define the semantics of
>>> non-integer parts.
>>>
>>> It might seem obvious at first - "peru" being "slight fork of
>>> micro-version 5". But perhaps sometimes a local branch wants to release a
>>> sneak preview, e.g. "almost micro-version 6".  Should that then be labeled
>>> 23.2.6-peru or (since 5-peru is taken already) 23.2.6.peru2?
>>>
>>> In Debian we allow both letters and digits in all parts, and use special
>>> sign "~" to indicate "almost" and "+" to indicate "just above". And we treat
>>> 0 (zero) equal to a missing trailing part. And more nitpicking...
>>>
>>> I do not, however, recommend you to adopt such complex scheme.  I suggest
>>> instead (as might actually be what imply by the above summary) that the 3
>>> first parts are strictly digits and intended only for mainline releases,
>>> while an optional 4th part is strictly for non-mainline use and allows
>>> [a-z0-9] (but nothing else - no dash, underscore, capital or non-ASCII
>>> letters, +~ or whatever). Then use simple C locale sort order, and leave it
>>> to local branches if they want to use only letters or also leading and/or
>>> trailing digits.
>>>
>>>  I am planing be more strict: the last part is only [a-zA-Z]*
>>
>
>  Then the next to 23.2.6-peru will be 23.2.7-peru or 23.2.6.1-peru. The
>> last part does not imply version, only is a helper to the local deployments.
>>
>
> So which package will be favored if all of the following are available:
>
>  23.2.7
>  23.2.7-peru
>  23.2.7-bolivia
>
> ?
>


No one. If Peru want a package to update 23.2.7, can create 23.2.7.1-peru or
23.2.8-peru
The reason is, we don't want use this part to set the order in the update.
We have groups of activities anyway, but if a user want to upgrade manually
a activity from other place can do it.


If last part "does not imply version", then they are all "flavors" of same
> version 23.2.7, yet one might be a bugfix of the other and the third a
> feature enhancement.
>
> Also, if you permit local branches to add more version parts, are they then
> allowed to add yet another part if need be?  What is the strict logic?
>
> Or do you not want a strict logic (now, but learn as you move on)?
>
>
> And why a "more strict" part if it does not imply version?  And if it does
> get used to resolve which of multiple flavors win an election, what is then
> the sorting algorithm when you permit both capital and lowercase letters?
>
>
Sorry, strictest.
The idea is not take in account the last part in the compute of the order of
the versions. I have excluded the numbers to do it more evident. Capital and
lowercase are the same, but we can limit if it's a problem.

We are changing from a  integer scheme for activities. I don't want over
complicate it, and assure the versions can be mapped to packages if
necesary.

Regards

Gonzalo


> Regards,
>
>
>  - Jonas
>
> --
>  * Jonas Smedegaard - idealist & Internet-arkitekt
>  * Tlf.: +45 40843136  Website: http://dr.jones.dk/
>
>  [x] quote me freely  [ ] ask before reusing  [ ] keep private
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iQIcBAEBCgAGBQJMqgLcAAoJECx8MUbBoAEh9HQP/0PsZp7WxO5CXm28tqSe/kMu
> 9kRZsVuG9ZmFgPQx6kTfYY8eGlyZWs6o+0HqsASjR+4BRs/l8eniiNwZR1ueR0mf
> 3nFG3sgtV00TcA26uQaIZjrLRPRihUOk92+HhPNwe+HMKVKA/tDPOzFg4xfBvDrD
> nyQmbD7U1EKC/uJHHTiyUnt8cclkrUKjmG6cYQnbCub5zkJu+2L4ydhAvp2ah8Eh
> gxHrRd6I/D9T9AW1wbh/RBvXxn3a8gLcpZLN6wbexIN/iUQy5mbieituFaiIf4/z
> il/9wVYYnSca4g6eFyBSS9JWOiss2C/xdJddrt+10bbY9g3gHLxg9/i6jZqCMfye
> 8tpap6dwLHYf/lY9Mr/dcrBXy7qzwD2W8y0dxfzt32b+7ZPFhv+efgxab5FNnzI3
> rXfxF88T7gdwuX/2oJv/SLoavxHyitY41Ol3T/A82TYl7tDNS65LfBn6NDJCcM/z
> XeVTxf2fcqWPvd4/cpGPsQ8KKS+SHPZNCmjb9fLVi58kEB35mD5H42dOPebGgJqF
> zWg6eozDWi9JsEe3E6XBwdRB2ae92TRsehC0lsZUOz7qDOkXR02cPbk0TQlFR5oM
> rqWchP4//VlXQQJAze+KybGfO2eM+69uYAz9MXzFPGggv1/N25ey29iwMANi/s58
> qeCsdjpSi2G5YZSASoLz
> =1b9O
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.sugarlabs.org/archive/sugar-devel/attachments/20101004/0ef93cf2/attachment.htm