On Mon, Sep 28, 2009 at 3:42 PM, Gary C Martin <g...@garycmartin.com> wrote:
> 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? > > So we end up with something like this in the .info that we may need to > update on every release: > > host_version = +0.82; -0.83; +0.84; +0.86 > 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: host_version = 0.86.0 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. 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: 1) Do the work to maintain backwards compatibility 2) Accept that users will experience crashes 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!) > 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. > I have a prototype patch which fixes the launch window and adds an error message. I'll try to get it posted soon. > [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 > http://wiki.sugarlabs.org/go/File:Toolbar-bug.png Awesome! Mind if I use this in http://wiki.sugarlabs.org/go/Features/Problem_Reports? > 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. > 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. Best, -Wade
_______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel