On Mon, Oct 4, 2010 at 1:37 PM, Jonas Smedegaard <d...@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@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > >
_______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel