<div class="gmail_quote">On Mon, Sep 28, 2009 at 3:42 PM, Gary C Martin <span dir="ltr"><<a href="mailto:gary@garycmartin.com">gary@garycmartin.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
My main concern is, "how will most developers know what versions of Sugar their activity will work under?" This is going to be an ever growing .info string that will need constant maintenance once added. Will it be a white list of sugar versions, a black list of sugar versions, a combination of both, with omissions assuming it works, or fails?<br>
<br>
So we end up with something like this in the .info that we may need to update on every release:<br>
<br>
host_version = +0.82; -0.83; +0.84; +0.86<br></blockquote><div><br></div><div>In the patch I posted, I assume that activities pick the oldest version of Sugar they are compatible with. For example, new Toolbar classes were introduced in 0.86, so the latest Terminal will write:</div>
<div><br></div><div>host_version = 0.86.0</div><div><br></div><div>If you are a lazy activity developer, you simply write the version that you tested the activity for. There is no + or -, since we assume that Sugar will not break old versions of activities with new releases. This is not a new concept; we have always had the monotonically incrementing host_version. It's just never been incremented (or properly supported) before.</div>
<div><br></div><div>I arrived here from a pragmatic place: I cloned Terminal from Gitorious and realized it doesn't launch on my version of Sugar (SoaS Strawberry). I briefly looked into fixing it, but didn't see the immediate way to do that. That left me with two options:</div>
<div><br></div><div>1) Do the work to maintain backwards compatibility </div><div>2) Accept that users will experience crashes</div><div><br></div><div>I'd much rather have a third option, especially if we plan to make further additions to the sugar toolkit along the lines of the new toolbars. (Aleksey's sugar-ports library does go a long way towards making 1 easier - way to go!)</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">I'd much rather put the effort into fixing the launch pulsing window, so it is not so stupid. It needs to recognise when a process failed to start, and, at the very least, exit quickly back to the rest of the UI.<br>
</blockquote><div><br></div><div>I have a prototype patch which fixes the launch window and adds an error message. I'll try to get it posted soon.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
[1] I cleaned up Walters TA bug icon for use in the new Log toolbar, but it didn't make it in this time around <a href="http://wiki.sugarlabs.org/go/File:Toolbar-bug.png" target="_blank">http://wiki.sugarlabs.org/go/File:Toolbar-bug.png</a></blockquote>
<div><br></div><div>Awesome! Mind if I use this in <a href="http://wiki.sugarlabs.org/go/Features/Problem_Reports">http://wiki.sugarlabs.org/go/Features/Problem_Reports</a>?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Sorry to be seeming to rain a little on the idea of release version checking, but I'm not sure most developers will ever fill this out correctly, and we're better of just being smarter about catching Activity (start-up) tracebacks quickly. And happy to help in this area if folks think this a good direction.<br>
</blockquote><div><br></div><div>I agree that it's not likely that developers will fill it out consistently, but at least they don't ever need to if they don't care about it. It's just a way for activity developers like me who want to inform users that their activities have a limit w.r.t. backwards compatibility.</div>
<div><br></div><div>Best,</div><div>-Wade</div></div>