Extremely informative Morgan, many thanks indeed. I am confused! >From a marketing & PR point of view (bear with me please) I find it very odd that a version used by hundreds of thousands of children is still zero point something. The nontechnical computer-using mind historically assumes v1.0 is the first production version, v2.0 adds features, and v3.0 reaches maturity with best performance and stability. This numbering has served Firefox well for example. And OpenOffice. Miro has been marketed like this too. And Audacity, with v1.2.x and now v1.3.x.
>From 0.82 to 0.84 doesn't sound like much to the nontechnical ear, yet 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 <[email protected]> wrote: > On Fri, Mar 6, 2009 at 09:55, Sean DALY <[email protected]> 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 easier > 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 > _______________________________________________ IAEP -- It's An Education Project (not a laptop project!) [email protected] http://lists.sugarlabs.org/listinfo/iaep
