[Sugar-devel] [ANNOUNCE] Sucrose 0.86 Branching - Activity versions

[Eben Eliason]

On Thu, Oct 1, 2009 at 7:16 AM, Peter Robinson <pbrobinson at gmail.com> wrote:
> On Thu, Oct 1, 2009 at 12:08 PM, Wade Brainerd <wadetb at gmail.com> wrote:
>> On Thu, Oct 1, 2009 at 5:20 AM, Simon Schampijer <simon at schampijer.de>
>> 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
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>