<div class="gmail_quote">On Mon, Oct 4, 2010 at 1:37 PM, Jonas Smedegaard <<a href="mailto:dr@jones.dk">dr@jones.dk</a>> wrote: <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> <div class="im">On Mon, Oct 04, 2010 at 12:50:37PM -0300, Gonzalo Odiard wrote: <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> Short version: Gogogo! Thanks! <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> 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. </blockquote> I am planing be more strict: the last part is only [a-zA-Z]* </blockquote> <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> 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. </blockquote> </div> So which package will be favored if all of the following are available: 23.2.7 23.2.7-peru 23.2.7-bolivia ? </blockquote><div> 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. </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> 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? </blockquote><div> Sorry, strictest. </div><div>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 </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> Regards,<div><div></div><div class="h5"> - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: <a href="http://dr.jones.dk/" target="_blank">http://dr.jones.dk/</a> [x] quote me freely [ ] ask before reusing [ ] keep private </div></div> -----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 <a href="mailto:Sugar-devel@lists.sugarlabs.org">Sugar-devel@lists.sugarlabs.org</a> <a href="http://lists.sugarlabs.org/listinfo/sugar-devel" target="_blank">http://lists.sugarlabs.org/listinfo/sugar-devel</a> </blockquote></div>