<div dir="ltr"><div><div><div><div>We can't go with 1.0 unless we change the numbering system.<br><br></div>The current system means it will take another decade to get to v3.0. I and perhaps others will have far more grey hair by then.<br> <br></div>I proposed several years ago that the developer version numbers (not to mention the OLPC OS version numbers) be separated from the marketing version numbers, since the dev version numbers are unmarketable. Developer resistance at the time was ferocious, a symptom of how marketing is widely considered irrelevant in the F/LOSS universe.<br> <br></div>We therefore reoriented version numbering for Sugar on a Stick "v6", which we rebaptized "v1 Strawberry". This strategy helped us obtain very wide press coverage at the time, since journalists and analysts (as intended) understood that release as "Sugar v1, a year after the spinoff from OLPC". This was appropriate, because Sugar was already shipping in production to hundreds of thousands of children.<br> <br></div>Today, communicating a v1 of Sugar is problematic, *unless* it is associated with a platform change, e.g. the transition to HTML-based (and ultimately Android-compatible) Activities; or presented as positioning Sugar for tablets; our narrative would be "a fresh start".<br> <div><br></div><div>In terms of timing, it's far more important to offer real change with a v1 than to meet a self-imposed deadline; if more time is needed, by all means it should be taken. A functioning HTML5 based toolkit, adapting to the form factor change towards tablets, Android compatibility (whatever form that may take), perhaps even an OEM partnership with Raspberry Pi Foundation or Google (Chromebook) or a social media giant, would not only greatly raise awareness, but provide a springboard for serious funding.<br> <br></div><div>At the same time, it will be vital to communicate our level of ongoing support (in the wide sense) to the existing installed base which of course will include the XO-4 recipients as it starts shipping.<br> <br> </div><div>I feel that 0.100 is even more unmarketable than 0.98. However, as a developer version number tucked away under the hood, I'd have no objection to that if it is helpful to getting the job done while a more understandable number is communicated to press and analysts.<br> </div><div><br>Sean<br>Sugar Labs Marketing Coordinator<br><br></div><div><br><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, May 17, 2013 at 3:21 PM, Walter Bender <span dir="ltr"><<a href="mailto:walter.bender@gmail.com" target="_blank">walter.bender@gmail.com</a>></span> wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Perfection is the enemy of the good.<br> <div><div class="h5"><br> On Fri, May 17, 2013 at 9:07 AM, Daniel Narvaez <<a href="mailto:dwnarvaez@gmail.com">dwnarvaez@gmail.com</a>> wrote:<br> > Hello,<br> ><br> > we need to decide if we want the next release to be 1.0 or 0.100.<br> ><br> > Here is the features we are planning for it.<br> ><br> > * Develop an HTML5 based toolkit for activities<br> ><br> > * Multiple selection in the Journal<br> > <a href="http://wiki.sugarlabs.org/go/Features/Multi_selection" target="_blank">http://wiki.sugarlabs.org/go/Features/Multi_selection</a><br> ><br> > * Enhanced support for 3G modems<br> > <a href="http://wiki.sugarlabs.org/go/Features/3G_Support/Database_Support" target="_blank">http://wiki.sugarlabs.org/go/Features/3G_Support/Database_Support</a><br> ><br> > * Background customization<br> > <a href="http://wiki.sugarlabs.org/go/Features/Background_image_on_home_view" target="_blank">http://wiki.sugarlabs.org/go/Features/Background_image_on_home_view</a><br> ><br> > * Multiple home views<br> > <a href="http://wiki.sugarlabs.org/go/Features/Multiple_home_views" target="_blank">http://wiki.sugarlabs.org/go/Features/Multiple_home_views</a><br> ><br> > * Integration with web services<br> > <a href="http://wiki.sugarlabs.org/go/Features/Web_services" target="_blank">http://wiki.sugarlabs.org/go/Features/Web_services</a><br> ><br> > * Journal comments box<br> > <a href="http://wiki.sugarlabs.org/go/Features/Comment_box_in_journal_detail_view" target="_blank">http://wiki.sugarlabs.org/go/Features/Comment_box_in_journal_detail_view</a><br> ><br> > * Icon customization<br> > <a href="http://wiki.sugarlabs.org/go/Features/Icon_Change" target="_blank">http://wiki.sugarlabs.org/go/Features/Icon_Change</a><br> ><br> ><br> > It's a bit of weird situation because code wise we are not really 1.0 ready.<br> > We are developing a new toolkit and the old one could use an API cleanup. On<br> > the other hand we are deployed to millions of users.<br> ><br> > Personally I don't really have a strong feeling. If the marketing team sees<br> > an opportunity in a 1.0 in October with the above feature list I'd say to go<br> > ahead with it even if from a developer point of view we are not ready.<br> > Otherwise we could delay it at least another cycle.<br> <br> </div></div>I think the marketing team had already reached consensus about 1.0.<br> But maybe Sean can chime in.<br> <br> <br> ><br> > --<br> > Daniel Narvaez<br> <div class="im">><br> > _______________________________________________<br> > Marketing mailing list<br> > <a href="mailto:Marketing@lists.sugarlabs.org">Marketing@lists.sugarlabs.org</a><br> > <a href="http://lists.sugarlabs.org/listinfo/marketing" target="_blank">http://lists.sugarlabs.org/listinfo/marketing</a><br> ><br> <br> </div>Plus, I think .100 is confusing.<br> <br> -walter<br> <br> --<br> Walter Bender<br> Sugar Labs<br> <a href="http://www.sugarlabs.org" target="_blank">http://www.sugarlabs.org</a><br> </blockquote></div><br></div>