No subject

I know there has been an enormous amount of work done these past few
months. At this numbering rate, Sugar will get to v1.0 in six years or
so, and v2.0 when today's kids are in university :-(

Now, what I am about to suggest might be sacrilegious and bring the
temple crashing down about my ears, and I don't wish to offend anyone,
but can we please consider a cleaner, more comprehensible numbering
system with this release? Parent- and teacher-facing, easily
understandable? And which could minimize impact on the
developer/deployment/package side?


Let's think about it:

* v1.0 doesn't seem to make sense right now, not only because it may
not seem justified from a 0.82 -> 0.83 -> 0.84 &c. point of view, but
because it would be weird to call a new version of an already
widely-deployed environment v1.0.

* v1.82, v1.84 could seem interesting, but that leaves the the only
second decimal place change which will still seem minor.

* v2.0 seems presumptuous and if there is more than a new version
every year, we will too quickly arrive at v5.0 and v6.0 and eventually
v12 like Corel Draw (and if memory serves, to avoid unlucky v13 they
went to... vX3 !)

* Or: We could lose the 0.8 and simply replace it with 1. So 0.82 ->
0.84 becomes 1.2 -> 1.4. Bugfixes could become v1.4.1, v1.4.2. This
seems to me a very good solution: the rule for changing the numbering
developer-side is easy to understand, the 8.2 / 0.82 confusion
disappears, bugfix releases have an appropriately minor decimal point;
but best of all, very easy to understand, communicate and market. It's
intuitive and appropriate that the version be 1.x considering the
installed base in production worldwide. A major milestone (I am
thinking in particular of a very robust and reliable Sugar on a Stick
which will have a major marketing push) could therefore be v2.0.


I am aware radical numbering changes are never easy and there are
surely issues I'm not aware of, such as upgrading XOs, package
managers, etc. But there *are* historical precedents, the best-known
perhaps being Word for Windows v2 which went to v6 - because the Mac
version was developed faster (and had a larger installed base at the
time) and went through v3, v4, and v5. Word 6.0 was the first version
called simply "Word", where the Mac and Windows feature sets and
version number were aligned on both platforms.


As a fairly basic user of Sugar on the XO (I G1G1'd these past two
years), I have never understood the mysteries of version numbering
aside from the "build number". I am pretty sure I have "build 767" on
my XOs, but if you were to ask me today what version of Sugar I have,
I would say it is either 8.2 or 0.82, I don't know which, except
developers prefer talking about "0.82". I'm really worried now about
communicating just what version is coming out to teachers and parents.


Now, if this proposal seems too radical a change, I'm all ears for how
to improve what we have and dispel the fog. I think we can agree the
existing numbering system is very confusing and will leave v1.0 much
further in the future than it should be...


thanks

Sean
Marketing Coordinator



On Fri, Mar 6, 2009 at 9:57 AM, Morgan Collett <morgan.collett at gmail.com> w=
rote:
> On Fri, Mar 6, 2009 at 09:55, Sean DALY <sdaly.be at gmail.com> wrote:
>> No, not nitpicking!
>>
>> Let's be clear what the version number is.
>>
>> I have seen both "0.84" and "8.4" and "8.4.0" and "8.4.1", and for the
>> nontechnical user the "build" number can be confusing.
>>
>> Which is it?
>
> 0.84.0. It's a release of software, not a build.
>
> The most confusion happened when OLPC released an operating system
> release called 8.2.0 containing a Sugar release version 0.82.0. We
> subsequently had a Sugar release 0.82.1, and OLPC's still working
> towards an 8.2.1 operating system release. The 8's and 2's and 0's had
> nothing to do with each other and it was an unfortunate coincidence...
> OLPC's numbering scheme had the 8 referring to 2008, the 2 being the
> second major release of the year, and the 0 (or 1) as a minor version
> number, with 8.2.1 intended to be a minor bugfix update to 8.2.0. (Now
> with 9.1.0 abandoned, 8.2.1 has grown in scope.)
>
> Roughly a year ago or so, Sugar packages had version numbers of
> 0.75.x, probably denoting roughly "three quarters finished" - since
> version 1.0 is usually a significant milestone for a project, often
> considered to be feature-complete. While 0.75.x was stabilizing for an
> OLPC release, new features were landed on a separate branch and
> released as 0.79.x releases. Only features approved by OLPC for
> inclusion (due to the semi-code-freeze) were then incorporated in
> 0.75.x.
>
> Since then, we had 0.81.x as a series of "unstable" or "developer"
> releases - snapshots of code under active development which were not
> particularly tested, which stabilized and led to the 0.82.0 stable
> release. This had bugs, some of which were fixed in the 0.82.1 stable
> release.
>
> This set in motion a plan to have odd numbers (0.81.x, 0.83.x) as
> unstable releases and even numbers (0.82.x, 0.84.x) as stable releases
> - as various other Free Software projects also do.
>
> If there were more developers, we could have continued support of this
> stable release and produced an 0.82.2 stable release while working on
> the 0.83.x unstable releases.
>
> 0.83.x unstable releases were produced, and once the feature freeze
> occurred the emphasis was on stabilizing and bug fixing, leading to
> the 0.84.0 stable release.
>
> The plan right now seems to be to work on bug fixes for 0.84.0 leading
> to an 0.84.1 stable release, which wouldn't have new features, just
> bug fixes.
>
> New features in the pipeline will land in the coming 0.85.x unstable
> releases, leading to an 0.86.0 release in about 6 months' time.
>
> Distributions are welcome to package the odd numbered unstable
> releases in developer snapshots, alpha releases etc to provide =A0easier
> testing of those milestones, but the releases most suitable for stable
> distro releases are the stable Sugar releases.
>
> Phew! I think there's an open spot on the Documentation Team for a
> Biographer of the project...
>
> Regards
> Morgan
>