On Thu, Oct 1, 2009 at 7:16 AM, Peter Robinson <[email protected]> wrote: > On Thu, Oct 1, 2009 at 12:08 PM, Wade Brainerd <[email protected]> wrote: >> On Thu, Oct 1, 2009 at 5:20 AM, Simon Schampijer <[email protected]> >> wrote: >>> >>> *Activity versions* >>> As we use integers for activity versions (this really has to change for >>> 0.88 with introducing minor versions), we need to cope for the famous: >>> stable/unstable version issue. I would say to leave at least 3 version >>> numbers open when doing a new unstable release. An example: >>> >>> Walter has submitted TurtleArt 69 for 0.86. He reserves the numbers 70, >>> 71, 72 for bug fix releases. When he is doing a release from the >>> unstable master branch (0.88 development) he is using numbers > 72.
This still seems pretty limiting. What if he finds he actually needs 4 bugfix releases? Why should replace a limited system with another that's just as limiting (This suggestion is kind of like going from O(0) to O(3), instead of O(n) like we really need). >> I'm still against this plan. Does anyone else feel like the integer numbers >> are a good thing? I think it's been argued that it would be easier for kids, though I've counter-argued that it's harder to make sense of integer versioning when it's just more confusing to attempt to map the natural numbers onto a non-linear space. The decimal notation helps make the branching more visible, which adds clarity in addition to complexity (and it's clear the complexity can't be gotten rid of). >> We have been striving to keep activity releases backwards compatible as far >> as possible; there should be no need to branch activities for sucrose >> releases. If a bug is found, sucrose can be updated to the latest version. > > I agree. why not have 69 as the primary release and fixes against it > for the branch as 69.1 69.2 etc. Or if its meant for a particular This definitely makes the most sense to me. I think that the major/minor distinction, where each portion of that version number is monotonically increasing, will keep things relatively simple without being too limiting. You can argue for major.minor.bugfix, too (which is more like O(n^2)), but chances are we'd all rather avoid that if possible. Of course, we could simply support version strings of this kind, but collectively agree to avoid the third field unless it's absolutely necessary. If we really want to keep integer version numbers, perhaps we should just "multiply by 10" and allot versions 10 at a time, so that major releases would go from 60 to 70 to 80, etc, leaving 9 (yes, still just a constant, O(9)) bugfix releases open per major version, but allowing us to talk about activities as the "60s" or "70s" instead of keeping track of which 3 or so versions run on which platform. It's worth noting that this would get us into 4 digit version numbers a lot faster, of course. It could be a terrible idea, but I'm just throwin' it out there. Eben > version of sugar and not meant to be compatible with earlier versions > use the same release as the release of sugar. It would at least be > easy to work out that version 86.x is needed for sugar 0.86.x as 69 > has no relationship what so ever. > > Peter > _______________________________________________ > Sugar-devel mailing list > [email protected] > http://lists.sugarlabs.org/listinfo/sugar-devel > _______________________________________________ Sugar-devel mailing list [email protected] http://lists.sugarlabs.org/listinfo/sugar-devel
