<div dir="ltr"><br><div class="gmail_extra">Thanks so much for the well thought feedback, Sean.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On 17 May 2013 18:04, Sean DALY <span dir="ltr"><<a href="mailto:sdaly.be@gmail.com" target="_blank">sdaly.be@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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>
</div></div></div></div></blockquote><div><br></div><div>Couple of things:<br></div><div><br></div><div>1 So this has never been discussed before with developers, but my opinion is that as soon as we have some automated tests in place we should move to continuous development. Which means version numbers would become pretty much irrelevant to developers. I'm not sure what other thinks and we probably shouldn't discuss that here to not sidetrack the thread.<br>
</div><div><br></div><div>2 All the power to marketing on this. I would be fine with you guys unilaterally choosing release numbers :)<br><br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr"><div><div><div></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>
</div></div></blockquote><div><br></div><div>There is an important point here. At the moment the release we are talking about is not a finished product, which is what you seem to think about. It's just something you can take a make a finished product with.<br>
</div><br></div><div class="gmail_quote">If we want to market a finished product we need to decide what that is. Is it Sugar on a Stick?<br></div><div class="gmail_quote"><br><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr"><div></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></blockquote><div><br></div><div>I'm not too convinced the next release will be a compelling demo of the html libraries. We don't have much time to write new cool activities mostly. Maybe we can still market the switch, I'm not keen about that but I don't know.<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></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.</div>
</div></blockquote><div><br></div><div>I think in a continuous development work we would basically "release" when we are ready. The code would be ready all the time and we would just decide when stuff is cool enough to make noise about it.<br>
<br></div><div>Though realistically for development I don't think this is the time to abandon 6 months time based released. I suggest we discuss that after this release. It shouldn't make much difference for marketing, devel release doesn't even need to be "public".<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>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>
</div></div></blockquote><div><br></div><div>Is anyone working on those partnerships? Is there anything developers can do to help them? Other than keeping to improve the software of course. And I'm sure a solid "port" to the Raspberry might be useful but... we need to chose what to focus on, it should something which has solid chances to happen.<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></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></blockquote><div><br></div><div>So perhaps we need to figure out what 1.0 (or whatever name marketing would like) should be and then developers will figure out the best way to make it happen :)<br><br></div><div>
The most pressing question to me is what it is that we are marketing exactly. Is it Sugar on a Stick? Is it the upstream code release (is that even marketable)? Or what is it?<br><br></div><div>I hope it's clear I would like marketing to have more of a say in the development direction. I don't know where we want to go, but I wish you guys could help us to figure that out.<br>
</div></div></div></div>