Re: [Sugar-devel] Proposal of dotted activity version number
On 10/22/2010 07:00 PM, Simon Schampijer wrote: On 10/07/2010 06:39 PM, Daniel Drake wrote: On 4 October 2010 15:27, Gonzalo Odiardgonz...@laptop.org wrote: What do others think about this approach? Packagers? A clearer way to discuss this would be to just send a patch. That way there is no doubt over the details of the implementation that you are proposing. Daniel Hi Daniel, that is what the current implementation looks like: http://bugs.sugarlabs.org/attachment/ticket/2425/normalized_version.patch Hope this helps, Simon I have been giving the patches another go and made some smaller fixes for error handling. I have tested them as well to make sure there are no regressions. I give them my ok. http://bugs.sugarlabs.org/attachment/ticket/2425/0001-Adopt-to-new-numbering-scheme-2425.patch http://bugs.sugarlabs.org/attachment/ticket/2425/0001-Add-new-numbering-scheme-2425.patch Comments? Regards, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Proposal of dotted activity version number
On Thu, Oct 28, 2010 at 3:58 PM, Simon Schampijer si...@schampijer.de wrote: I have been giving the patches another go and made some smaller fixes for error handling. I have tested them as well to make sure there are no regressions. I give them my ok. http://bugs.sugarlabs.org/attachment/ticket/2425/0001-Adopt-to-new-numbering-scheme-2425.patch http://bugs.sugarlabs.org/attachment/ticket/2425/0001-Add-new-numbering-scheme-2425.patch Where's the documentation? Does this code correspond to a concrete proposal? Or do we expect contributors to reverse engineer the version scheme from pydoc sugar.bundle.bundleversion? --scott -- ( http://cscott.net/ ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Proposal of dotted activity version number
On 10/07/2010 06:39 PM, Daniel Drake wrote: On 4 October 2010 15:27, Gonzalo Odiardgonz...@laptop.org wrote: What do others think about this approach? Packagers? A clearer way to discuss this would be to just send a patch. That way there is no doubt over the details of the implementation that you are proposing. Daniel Hi Daniel, that is what the current implementation looks like: http://bugs.sugarlabs.org/attachment/ticket/2425/normalized_version.patch Hope this helps, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Proposal of dotted activity version number
On Thu, Oct 7, 2010 at 12:39 PM, Daniel Drake d...@laptop.org wrote: On 4 October 2010 15:27, Gonzalo Odiard gonz...@laptop.org wrote: What do others think about this approach? Packagers? A clearer way to discuss this would be to just send a patch. That way there is no doubt over the details of the implementation that you are proposing. I object to implementations without documentation, on principle. --scott -- ( http://cscott.net/ ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Proposal of dotted activity version number
On 7 October 2010 21:54, Gonzalo Odiard gonz...@laptop.org wrote: Ticket with the start of implementation: http://bugs.sugarlabs.org/ticket/2425 Gonzalo I'm not sure which way would be best, but I would choose either a very simple solution (just dotted numbers, no alphanumerics) or a tried-and-tested solution i.e. carbon copy of debian/fedora/gnome apps versioning. In any case, something more expressive than an integer is needed and I'm all for it. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Proposal of dotted activity version number
On 10/06/2010 11:15 PM, C. Scott Ananian wrote: On Wed, Oct 6, 2010 at 5:00 PM, Martin Langhoff martin.langh...@gmail.com wrote: Initially, I advocated strongly for something with the expresiveness of dpkg's versioning. However, that's wrong. We need to use a clear _subset_ of what dpkg, rpm, portage(... etc) can do, so the distro packager retains its flexibility (see: epoch). Defining the version string as identical to the pre-epoch portion of a debian version string says a lot more in 11 words -- and with more precision -- than the entirely of the dotted version string proposal so far. This is the power we get from *building* on other's work, instead of reinventing it. (But we should remember what problem debian is solving with epoch numbers, and think really hard about why this could never ever ever happen to us before getting rid of them.) You could make a similar proposal based on redhat version strings, etc. We all *think* we need a subset right now. And then you'll find that subset grow, and mutate, etc, etc. We are all better off if we implement a well understood standard, even if we don't think we need all of its power immediately. It is true, dpkg considers 1.1-peru to be an upgrade over 1.1-argentina, due to alpha ordering. But that has no useful meaning. My personal feeling is that the peru and argentina part isn't really a version number, it's something else, which is misplaced here. But I don't feel as strongly about that. Either solve the problem correctly, or solve it as simply as possible. This solves it as simply as possible. I've outlined several simpler solutions. QED. Again, I think either the slightly more complicated (but more precise and easier to describe) solution (debian version numbers, exactly), or a simpler solution (say, just use only even version numbers for upstream releases, save odd numbers for localization teams) is preferred to the present proposal, which I think is both too complicated (by defining its own ad-hoc version string semantics) and too simple (0.1 possible, 0.0.1 impossible, at least according tohttp://wiki.sugarlabs.org/go/Features/Dotted_Activity_Versions). That page is outdated. The proposal is laid out in Gonzalo's initial mail. Sorry for the confusion. Regards, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Proposal of dotted activity version number
So the proposed 1.2.3-peru numbering scheme really is a 1.2.3 scheme with an optional trailing taint hint? It probably makes better sense to clearly distinguish those two essentially separate issues: * mainline numbering + integer + triple integers + Debian-style triple string scheme + other? * how to officially handle slight forks + extending triple integers with fourth integer/string + non-version suffix to version + separate field + no official support + other? The easiest for Debian would be if you version your code using triple integers, as that properly supports multiple branches (which you _are_ doing, whether you admit it or not!). debian care not about deployment forks, but I sure recommend that you do support it properly - which means make room for it in the versioning string and admit that forks are versioned too - not only a non-versioned flag. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Proposal of dotted activity version number
On Thu, Oct 07, 2010 at 12:45:11PM -0300, Gonzalo Odiard wrote: On Thu, Oct 7, 2010 at 12:22 PM, Jonas Smedegaard d...@jones.dk wrote: So the proposed 1.2.3-peru numbering scheme really is a 1.2.3 scheme with an optional trailing taint hint? [snip] It probably makes better sense to clearly distinguish those two essentially separate issues: [snip] It's clear in the previous examples? Nope. You insist on discussing both issues together. Very confusing. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Proposal of dotted activity version number
Ticket with the start of implementation: http://bugs.sugarlabs.org/ticket/2425 Gonzalo On Thu, Oct 7, 2010 at 1:39 PM, Daniel Drake d...@laptop.org wrote: On 4 October 2010 15:27, Gonzalo Odiard gonz...@laptop.org wrote: What do others think about this approach? Packagers? A clearer way to discuss this would be to just send a patch. That way there is no doubt over the details of the implementation that you are proposing. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Proposal of dotted activity version number
On Tue, Oct 5, 2010 at 9:49 PM, C. Scott Ananian csc...@laptop.org wrote: If you're going to use something other than simple integers, I suggest either: a) a string of dotted integers. You should *always* be able to subdivide a release if necessary. Strings like peru belong (in my opinion) in release notes or the name of the activity or anywhere else. They don't tell you anything about version ordering. If the problem is that you can't put a new release between 0 and 1, why are you creating a system that causes the same problem, except between 0.0.0 and 0.0.1? Yes, you are right. The string part don't tell us anything about version ordering The idea is use a string of dotted integers to indicate the order and the string part only to indicate a customization. Why? We have activity groups today for this. Because a teacher, a kid or a technician from Uruguay can see Peru have a customization, download, test and use. But the customization part does not imply order because it's not logic use the alphabetic order (Peru Ruanda Uruguay?) Then I plan to ignore the customization when I compute the order. b) use the debian version numbering system *exactly*. It has been shown to work in the real world, and it is well documented. The current proposal is neither (yet). We do not need to burden the world with yet another ad-hoc numbering system. Please build on other people's work instead of re-inventing the wheel. Just because the debian system has features you don't *think* you need (yet) is not a reason to bypass it. There are great benefits to sharing a commons. I agree with not reinvent the wheel, but not with using the debian versions. Why not the Fedora, Gentoo or OSX? If you want, we will be using the linux kernel numbering system :) Of course, my preference is to keep the existing simple integers and solve the version precedence problem in other ways. Perhaps important activities should be encouraged to count by ten when increasing verson numbers -- or perhaps the tight dependency of Browse on a given Sugar version should be fixed. Integer number does not solve the problems we have today. Not the problems of the developers, but the downstreams. I am working with OLPC fixing Browse in sugar 0.84. The version we are using is Browse 108, but I cant release Browse 109 because already exists. The same problem we have, will have Dextrose or anybody who maintains a older branch. And count by ten it's not a good idea. A truely forward-thinking replacement would replace the integer version numbers with a git-style version tree. Just say, this activity replaces the activity bundle with manifest hash abcdef. That is more decentralized, and more accurate. Each activity could/should contain a list of URLs describing the canonical source for both itself (authoritative) and its (say) 10 immediate parents (non-authoritative). This proposal could be elaborated -- and it paves the way for a truely decentralized activity repository, where activities are created *and hosted* by children *on their own machines*. (Isn't this stil the vision of Sugar?) No. Git it's fantastic but it's not the solution to all. That would be a clear example of Second system effect [1] Gonzalo [1] http://en.wikipedia.org/wiki/Second-system_effect --scott ___ 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
Re: [Sugar-devel] Proposal of dotted activity version number
On Wed, Oct 6, 2010 at 6:58 AM, Gonzalo Odiard gonz...@laptop.org wrote: Then I plan to ignore the customization when I compute the order. So why is it there? b) use the debian version numbering system *exactly*. It has been shown to work in the real world, and it is well documented. The current proposal is neither (yet). We do not need to burden the world with yet another ad-hoc numbering system. Please build on other people's work instead of re-inventing the wheel. Just because the debian system has features you don't *think* you need (yet) is not a reason to bypass it. There are great benefits to sharing a commons. I agree with not reinvent the wheel, but not with using the debian versions. Why not the Fedora, Gentoo or OSX? If you want, we will be using the linux kernel numbering system :) Yes, please. Using anything from the *commons* instead of inventing a new *bespoke* system is preferable. Build connected communities, not islands. I am working with OLPC fixing Browse in sugar 0.84. The version we are using is Browse 108, but I cant release Browse 109 because already exists. The same problem we have, will have Dextrose or anybody who maintains a older branch. And count by ten it's not a good idea. Seems like count by ten solves the particular problem you have. It's the simplest possible solution that could work, which is a surefire way to avoid Second system effect [1] [1] http://en.wikipedia.org/wiki/Second-system_effect Either solve the problem correctly, or solve it as simply as possible. The current proposal does neither, and just adds a new layer of poorly documented ad-hoc-ery. --scott -- ( http://cscott.net/ ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Proposal of dotted activity version number
On Wed, Oct 6, 2010 at 4:47 PM, C. Scott Ananian csc...@laptop.org wrote: On Wed, Oct 6, 2010 at 6:58 AM, Gonzalo Odiard gonz...@laptop.org wrote: Then I plan to ignore the customization when I compute the order. So why is it there? To allow identification. But what Gonzalo pointed out is that in the case of 1.1-peru vs 1.1-argentina, vs 1.1, it makes sense to match them as equal. They shouldn't trigger an upgrade from one to the other. I had a long chat with Gonzalo on the topic of versioning. Initially, I advocated strongly for something with the expresiveness of dpkg's versioning. However, that's wrong. We need to use a clear _subset_ of what dpkg, rpm, portage(... etc) can do, so the distro packager retains its flexibility (see: epoch). It is true, dpkg considers 1.1-peru to be an upgrade over 1.1-argentina, due to alpha ordering. But that has no useful meaning. Either solve the problem correctly, or solve it as simply as possible. This solves it as simply as possible. m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Proposal of dotted activity version number
On Wed, Oct 6, 2010 at 5:00 PM, Martin Langhoff martin.langh...@gmail.com wrote: Initially, I advocated strongly for something with the expresiveness of dpkg's versioning. However, that's wrong. We need to use a clear _subset_ of what dpkg, rpm, portage(... etc) can do, so the distro packager retains its flexibility (see: epoch). Defining the version string as identical to the pre-epoch portion of a debian version string says a lot more in 11 words -- and with more precision -- than the entirely of the dotted version string proposal so far. This is the power we get from *building* on other's work, instead of reinventing it. (But we should remember what problem debian is solving with epoch numbers, and think really hard about why this could never ever ever happen to us before getting rid of them.) You could make a similar proposal based on redhat version strings, etc. We all *think* we need a subset right now. And then you'll find that subset grow, and mutate, etc, etc. We are all better off if we implement a well understood standard, even if we don't think we need all of its power immediately. It is true, dpkg considers 1.1-peru to be an upgrade over 1.1-argentina, due to alpha ordering. But that has no useful meaning. My personal feeling is that the peru and argentina part isn't really a version number, it's something else, which is misplaced here. But I don't feel as strongly about that. Either solve the problem correctly, or solve it as simply as possible. This solves it as simply as possible. I've outlined several simpler solutions. QED. Again, I think either the slightly more complicated (but more precise and easier to describe) solution (debian version numbers, exactly), or a simpler solution (say, just use only even version numbers for upstream releases, save odd numbers for localization teams) is preferred to the present proposal, which I think is both too complicated (by defining its own ad-hoc version string semantics) and too simple (0.1 possible, 0.0.1 impossible, at least according tohttp://wiki.sugarlabs.org/go/Features/Dotted_Activity_Versions). I think that's exactly the wrong way to optimize. Sugar doesn't need yet another ad-hoc undocumented scheme. --scott -- ( http://cscott.net/ ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Proposal of dotted activity version number
I support the proposal for dotted activity version numbers, but I don't like at all the idea of using -peru or -something on the end that isn't a version number. It should go in some other metadata. I agree with Scott too. -- James Cameron System Test Coordinator One Laptop per Child ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Proposal of dotted activity version number
On 10/05/2010 01:16 AM, Tim McNamara wrote: On 5 October 2010 10:25, James Cameronqu...@laptop.org wrote: I agree with the proposal. -- James Cameron System Test Coordinator One Laptop per Child I tentatively agree. My strong preference is for Activities to rapidly increase their integer numbers, rather than creating a complex tree of point releases. My feeling is that a tree of three or more levels deep adds complexity to new Learners. It goes against the 'low floor, no ceiling' philosophy by requiring that Learners learn a new counting system, on top of integer increments. It also adds to the pressure to maintain several versions of the software concurrently. While I agree that maintainence releases are important, I would prefer that community etiquette is developed that discourages version numbers that look like 2.4.12. Developers should be strongly encouraged to migrate to a new integer release when practical. Most activities are quite discrete. They tend not to add many features once they have reached a desired level of maturity. Tim. Hi Tim, I think most of the activities will keep on just using integer numbers. The new proposal does address only the need where this is not possible or where we would have to find even uglier solutions (like described in the original mail). I think the most complex version number we will ever see is 10.2. Btw, the current scheme resulted in activity numbers like 108 for Browse. This is the case since we had many development iterations. When we would have used the versioning scheme with minor major release we would probably be at 8.0 by now, which I tend to think might be easier for young learners (if they will ever look at the version numbers). Regards, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Proposal of dotted activity version number
Hi Gary, thanks for your feedback. On 10/05/2010 04:31 AM, Gary Martin wrote: On 5 Oct 2010, at 00:30, James Cameronqu...@laptop.org wrote: On 05/10/2010, at 10:16 AM, Tim McNamara wrote: My strong preference is for Activities to rapidly increase their integer numbers, rather than creating a complex tree of point releases. My feeling is that a tree of three or more levels deep adds complexity to new Learners. It goes against the 'low floor, no ceiling' philosophy by requiring that Learners learn a new counting system, on top of integer increments. Tentative +0.25 as well if others think this is really, really necessary - but I personally never want to have to maintain two or more versions of any activity (what the doted version support is really all about). When we hit a show stopping api break, consider the last working release the end of line, or upgrade to a newer Sugar that is supported by a newer activity release. Fair enough. Personally I think the new scheme is used in the following cases: * platform dependent activities like Browse or Read * I want to do several small releases (for example for people for testing, 1.2, 1.3, 1.4) before I get to a new major release (2). Yes. Better than the current situation though. Only if the change does not break 0.82 and 0.84 integer based updates/installs. Or are we saying that as of 0.92 every activity will have to fork and break with past versions of Sugar anyway? If so I can see little motivation as an activity developer to move to 0.92 for quite some time, who wants to write activities almost no deployment will use for likely 6 to 18 months at best? I guess if this is the case, moving to a new versioning scheme in 0.92 is fine even if it breaks 0.82 and 0.84, as no activities for 0.92 will run anyway on past Sugar versions :( Of course we don't break backwards compatibility. Integer versions will work as they did before. Ideally, instead of presenting a version number to a learner, a graph describing the history of the activity source and dependencies could be displayed. Ouch. Alternatively, separate the Learner visible numbering from the software release numbering, and leave the visible numbering within the scope of a deployment. Then one deployment's Browse-190 may be different to another deployment's Browse-190. Oh please for the love of maintenance no, how will we ever deal with bug reports. If a deployment decides to fork, say Physics, and introduces their own bugs and/or breaks Journal entry compatibility by adding some feature, I do not want to burn up any more of my life dealing with tickets reported with ambiguous version information, it's bad enough dealing with tickets from folks not testing against the current release. If you fork you are on your own. Period. And I would encourage everyone to always upstream changes. But in some cases it is good and desired to fork for a moment (trying something out, or the change is just not interesting to upstream at all). Those cases would be supported by the new scheme. Regards, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Proposal of dotted activity version number
If you're going to use something other than simple integers, I suggest either: a) a string of dotted integers. You should *always* be able to subdivide a release if necessary. Strings like peru belong (in my opinion) in release notes or the name of the activity or anywhere else. They don't tell you anything about version ordering. If the problem is that you can't put a new release between 0 and 1, why are you creating a system that causes the same problem, except between 0.0.0 and 0.0.1? b) use the debian version numbering system *exactly*. It has been shown to work in the real world, and it is well documented. The current proposal is neither (yet). We do not need to burden the world with yet another ad-hoc numbering system. Please build on other people's work instead of re-inventing the wheel. Just because the debian system has features you don't *think* you need (yet) is not a reason to bypass it. There are great benefits to sharing a commons. Of course, my preference is to keep the existing simple integers and solve the version precedence problem in other ways. Perhaps important activities should be encouraged to count by ten when increasing verson numbers -- or perhaps the tight dependency of Browse on a given Sugar version should be fixed. A truely forward-thinking replacement would replace the integer version numbers with a git-style version tree. Just say, this activity replaces the activity bundle with manifest hash abcdef. That is more decentralized, and more accurate. Each activity could/should contain a list of URLs describing the canonical source for both itself (authoritative) and its (say) 10 immediate parents (non-authoritative). This proposal could be elaborated -- and it paves the way for a truely decentralized activity repository, where activities are created *and hosted* by children *on their own machines*. (Isn't this stil the vision of Sugar?) --scott ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Proposal of dotted activity version number
The current activity version scheme does only allow the use of integer numbers. This has the issue that doing a bug fix release for an older activity version gets rather complicated. People have been planning for that in advance and reserved numbers for such a purpose in order to overcome that short coming. Furthermore, the current scheme does not allow local deployments to release local versions of an activity. Based on the work that has been started in the Dotted Activity Versions feature [1] I want to propose a new scheme that fixes the issues described above. The new version number will consist of N integer numbers separated by dots and a suffix for a local indicator. Activity developers can still use an integer number only, if desired. Valid numbers are: 23 23.2 23.2.5 23.2.5-peru 23.2.5-uru The internal representation will be a string instead of an int and we will add means to validate and compare the versions. What do others think about this approach? Packagers? We must limit the number of integer digits allowed? Regards Gonzalo [1] http://wiki.sugarlabs.org/go/Features/Dotted_Activity_Versions ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Proposal of dotted activity version number
On Mon, Oct 4, 2010 at 10:27 AM, Gonzalo Odiard gonz...@laptop.org wrote: The current activity version scheme does only allow the use of integer numbers. This has the issue that doing a bug fix release for an older activity version gets rather complicated. People have been planning for that in advance and reserved numbers for such a purpose in order to overcome that short coming. How often is it the case that we wouldn't just want the latest version of an activity to replace a bug-laden older version? Is there a use case? That said, I have no objection to adding dotted version numbers. Furthermore, the current scheme does not allow local deployments to release local versions of an activity. Based on the work that has been started in the Dotted Activity Versions feature [1] I want to propose a new scheme that fixes the issues described above. The new version number will consist of N integer numbers separated by dots and a suffix for a local indicator. Activity developers can still use an integer number only, if desired. Valid numbers are: 23 23.2 23.2.5 23.2.5-peru 23.2.5-uru The internal representation will be a string instead of an int and we will add means to validate and compare the versions. What do others think about this approach? Packagers? We must limit the number of integer digits allowed? Regards Gonzalo [1] http://wiki.sugarlabs.org/go/Features/Dotted_Activity_Versions ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Proposal of dotted activity version number
On 10/04/2010 04:48 PM, Walter Bender wrote: On Mon, Oct 4, 2010 at 10:27 AM, Gonzalo Odiardgonz...@laptop.org wrote: The current activity version scheme does only allow the use of integer numbers. This has the issue that doing a bug fix release for an older activity version gets rather complicated. People have been planning for that in advance and reserved numbers for such a purpose in order to overcome that short coming. How often is it the case that we wouldn't just want the latest version of an activity to replace a bug-laden older version? There are cases where this is not possible. Take Browse as an example. Browse is highly tight to the underlying Sucrose version, hence Browse from 0.90 won't run on 0.84. If one has released Browse version 108 for Sucrose 0.84 and 109 for 0.86 one is in deep trouble if one wants to fix a bug in 0.84. So this is one use case where the extended scheme makes sense. I think it is much more flexible in general, and the good part is that people can still keep on using the integer version number. Regards, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Proposal of dotted activity version number
On Mon, Oct 04, 2010 at 11:27:36AM -0300, Gonzalo Odiard wrote: The new version number will consist of N integer numbers separated by dots and a suffix for a local indicator. Activity developers can still use an integer number only, if desired. Valid numbers are: 23 23.2 23.2.5 23.2.5-peru 23.2.5-uru The internal representation will be a string instead of an int and we will add means to validate and compare the versions. What do others think about this approach? Packagers? We must limit the number of integer digits allowed? 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. Enjoy, - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Proposal of dotted activity version number
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. Gonzalo Enjoy, - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Proposal of dotted activity version number
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 ? 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? Regards, - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Proposal of dotted activity version number
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
Re: [Sugar-devel] Proposal of dotted activity version number
Hi Gonzalo and others, I suspect we talk past each others. But let's just leave it at that. Good luck with the proposal! - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Proposal of dotted activity version number
I agree with the proposal. -- James Cameron System Test Coordinator One Laptop per Child ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Proposal of dotted activity version number
On Mon, Oct 4, 2010 at 5:25 PM, James Cameron qu...@laptop.org wrote: I agree with the proposal. +1 -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Proposal of dotted activity version number
On 5 October 2010 10:25, James Cameron qu...@laptop.org wrote: I agree with the proposal. -- James Cameron System Test Coordinator One Laptop per Child I tentatively agree. My strong preference is for Activities to rapidly increase their integer numbers, rather than creating a complex tree of point releases. My feeling is that a tree of three or more levels deep adds complexity to new Learners. It goes against the 'low floor, no ceiling' philosophy by requiring that Learners learn a new counting system, on top of integer increments. It also adds to the pressure to maintain several versions of the software concurrently. While I agree that maintainence releases are important, I would prefer that community etiquette is developed that discourages version numbers that look like 2.4.12. Developers should be strongly encouraged to migrate to a new integer release when practical. Most activities are quite discrete. They tend not to add many features once they have reached a desired level of maturity. Tim. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Proposal of dotted activity version number
On 5 Oct 2010, at 00:30, James Cameron qu...@laptop.org wrote: On 05/10/2010, at 10:16 AM, Tim McNamara wrote: My strong preference is for Activities to rapidly increase their integer numbers, rather than creating a complex tree of point releases. My feeling is that a tree of three or more levels deep adds complexity to new Learners. It goes against the 'low floor, no ceiling' philosophy by requiring that Learners learn a new counting system, on top of integer increments. Tentative +0.25 as well if others think this is really, really necessary - but I personally never want to have to maintain two or more versions of any activity (what the doted version support is really all about). When we hit a show stopping api break, consider the last working release the end of line, or upgrade to a newer Sugar that is supported by a newer activity release. Yes. Better than the current situation though. Only if the change does not break 0.82 and 0.84 integer based updates/installs. Or are we saying that as of 0.92 every activity will have to fork and break with past versions of Sugar anyway? If so I can see little motivation as an activity developer to move to 0.92 for quite some time, who wants to write activities almost no deployment will use for likely 6 to 18 months at best? I guess if this is the case, moving to a new versioning scheme in 0.92 is fine even if it breaks 0.82 and 0.84, as no activities for 0.92 will run anyway on past Sugar versions :( Ideally, instead of presenting a version number to a learner, a graph describing the history of the activity source and dependencies could be displayed. Ouch. Alternatively, separate the Learner visible numbering from the software release numbering, and leave the visible numbering within the scope of a deployment. Then one deployment's Browse-190 may be different to another deployment's Browse-190. Oh please for the love of maintenance no, how will we ever deal with bug reports. If a deployment decides to fork, say Physics, and introduces their own bugs and/or breaks Journal entry compatibility by adding some feature, I do not want to burn up any more of my life dealing with tickets reported with ambiguous version information, it's bad enough dealing with tickets from folks not testing against the current release. Regards, --Gary -- James Cameron System Test Coordinator One Laptop per Child ___ 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
