[Sugar-devel] Proposal of dotted activity version number

Gonzalo Odiard gonzalo at laptop.org
Mon Oct 4 13:58:29 EDT 2010

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 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 or
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



> Regards,
>  - Jonas
> --
>  * Jonas Smedegaard - idealist & Internet-arkitekt
>  * Tlf.: +45 40843136  Website: http://dr.jones.dk/
>  [x] quote me freely  [ ] ask before reusing  [ ] keep private
> Version: GnuPG v1.4.10 (GNU/Linux)
> 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
> _______________________________________________
> 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 

More information about the Sugar-devel mailing list