[Sugar-devel] Proposal of dotted activity version number
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!
>> 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 184.108.40.206-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:
No one. If Peru want a package to update 23.2.7, can create 220.127.116.11-peru 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?
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
> - 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)
> -----END PGP SIGNATURE-----
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Sugar-devel