Re: [Sugar-devel] Activity Versioning (Was Re: [RELEASE] Terminal v24)
On Thu, Mar 19, 2009 at 6:05 AM, Tomeu Vizoso to...@sugarlabs.org wrote: On Wed, Mar 11, 2009 at 18:34, Wade Brainerd wad...@gmail.com wrote: On Wed, Mar 11, 2009 at 1:17 PM, Eben Eliason e...@laptop.org wrote: On Wed, Mar 11, 2009 at 1:05 PM, Wade Brainerd wad...@gmail.com wrote: On Wed, Mar 11, 2009 at 12:05 PM, Tomeu Vizoso to...@sugarlabs.org wrote: On Wed, Mar 11, 2009 at 17:00, Eben Eliason e...@laptop.org wrote: Here is some (OK, a lot) of background reading on the subject. I still cast my vote for a major/minor distinction, as mentioned in my response on the second thread below. http://www.mail-archive.com/de...@lists.laptop.org/msg11149.html http://www.mail-archive.com/su...@lists.laptop.org/msg03283.html That's also my favorite right now. I actually have the exact opposite instinct, coming at it from the user's perspective. The best choice for *users* is to keep the linearly incrementing version, and document which activity versions work with which Sugar versions. The activities.sugarlabs.org system already has an easy way to see what application versions an activity version works with. We should strive to ensure that newer versions of activities will work with older versions of Sugar or else fail gracefully. Eben's idea to I think this might be a big assumption to make. Sugar could include new libraries at some point. We could add additional classes and controls to the toolkit. There could be a fundamental change in the protocol for some activity or service. Obviously we'd prefer to keep backward compatibility, but can we promise it always and indefinitely? show activity startup failure information on the launcher screen would help a lot with the fail gracefully part. If we wait until activity launch to inform the user a particular activity won't work for them, we'd better be quite certain that it's easy to revert the update. Being able to branch activities would perhaps help the Sugar development team. But for the users, in this situation it would be best to make a new Terminal 25 that works with 0.86 and 0.84, and then update 0.84 to reference that. Think about it this way- someone with 0.84 can go *right now* and download Terminal v24 or later. So why can't we just update 0.84 to reference Terminal v24+ if a bug is found in v23? This could be ideal if every newer version will always work with older versions of Sugar. Consider, though, that some bugs might only exist on older versions of Sugar. Would we want to push an update to everyone for this? Also, it still seems clearest to me to be able to make statements like versions 21–23 of Terminal work on 0.84 and version 24 works on 0.86 (where versions have one or more implicit .x minor versions). With the major-version-only approach (and assuming we don't have full backward compatibility), we have to resort to statements like versions 21–23 and also 25 work on 0.84, and versions 24 and 26 work on 0.86. - Eben Regards, Wade Ultimately I think this all comes down to putting the responsibility for stability and compatibility on the developer instead of the user. As soon as we add those minor numbers, people's eyes will glaze over and the support emails will start rolling in :) If the Sugar developers are responsible about keeping the API compatible, and if Activity developers are responsible about responding to bug reports and maintaining compatibility, the situation you are describing will not happen. Generally speaking we are talking about theoretical exceptions here anyway - I can't think of a situation where it's actually happened, except perhaps with Browse whose code I argue should be part of the Sugar toolkit anyway. Consider that some stupid DOS program I wrote back in 1995 still works just fine on the Windows 7 Beta - that's some impressive binary compatibility. We don't have to go that far, we just have to maintain the DBus protocol for C (and eventually other) activities and the Sugar toolkit API for Python activities. I think this is perfectly doable, but will take substantial testing and coding effort to reach the goal of backwards compatibility. And right now I don't see those resources available. We have few people working on the Sugar core but a lot of activity authors. May be wiser to move that responsibility from the development team to the activity team? Yes, that's absolutely fine with me. We already work around differences in things like Python version all the time. It's just a matter of building up our bag of tricks and making sure it's applied consistently. http://git.sugarlabs.org/projects/finance/repos/json/blobs/master/finance.py#line23 Best, Wade Regards, Tomeu ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity Versioning (Was Re: [RELEASE] Terminal v24)
One project to look for on how to handle activity versions is eclipse. The notion of the eclipse plug-in ecosystem is virtually the same as it is in Sugar Labs. Eclipse has a few years of struggling with this issue under their belt. http://www.eclipse.org/equinox/documents/plugin-versioning.html http://wiki.eclipse.org/index.php/Version_Numbering david On Wed, Mar 11, 2009 at 12:34 PM, Wade Brainerd wad...@gmail.com wrote: On Wed, Mar 11, 2009 at 1:17 PM, Eben Eliason e...@laptop.org wrote: On Wed, Mar 11, 2009 at 1:05 PM, Wade Brainerd wad...@gmail.com wrote: On Wed, Mar 11, 2009 at 12:05 PM, Tomeu Vizoso to...@sugarlabs.org wrote: On Wed, Mar 11, 2009 at 17:00, Eben Eliason e...@laptop.org wrote: Here is some (OK, a lot) of background reading on the subject. I still cast my vote for a major/minor distinction, as mentioned in my response on the second thread below. http://www.mail-archive.com/de...@lists.laptop.org/msg11149.html http://www.mail-archive.com/su...@lists.laptop.org/msg03283.html That's also my favorite right now. I actually have the exact opposite instinct, coming at it from the user's perspective. The best choice for *users* is to keep the linearly incrementing version, and document which activity versions work with which Sugar versions. The activities.sugarlabs.org system already has an easy way to see what application versions an activity version works with. We should strive to ensure that newer versions of activities will work with older versions of Sugar or else fail gracefully. Eben's idea to I think this might be a big assumption to make. Sugar could include new libraries at some point. We could add additional classes and controls to the toolkit. There could be a fundamental change in the protocol for some activity or service. Obviously we'd prefer to keep backward compatibility, but can we promise it always and indefinitely? show activity startup failure information on the launcher screen would help a lot with the fail gracefully part. If we wait until activity launch to inform the user a particular activity won't work for them, we'd better be quite certain that it's easy to revert the update. Being able to branch activities would perhaps help the Sugar development team. But for the users, in this situation it would be best to make a new Terminal 25 that works with 0.86 and 0.84, and then update 0.84 to reference that. Think about it this way- someone with 0.84 can go *right now* and download Terminal v24 or later. So why can't we just update 0.84 to reference Terminal v24+ if a bug is found in v23? This could be ideal if every newer version will always work with older versions of Sugar. Consider, though, that some bugs might only exist on older versions of Sugar. Would we want to push an update to everyone for this? Also, it still seems clearest to me to be able to make statements like versions 21–23 of Terminal work on 0.84 and version 24 works on 0.86 (where versions have one or more implicit .x minor versions). With the major-version-only approach (and assuming we don't have full backward compatibility), we have to resort to statements like versions 21–23 and also 25 work on 0.84, and versions 24 and 26 work on 0.86. - Eben Regards, Wade Ultimately I think this all comes down to putting the responsibility for stability and compatibility on the developer instead of the user. As soon as we add those minor numbers, people's eyes will glaze over and the support emails will start rolling in :) If the Sugar developers are responsible about keeping the API compatible, and if Activity developers are responsible about responding to bug reports and maintaining compatibility, the situation you are describing will not happen. Generally speaking we are talking about theoretical exceptions here anyway - I can't think of a situation where it's actually happened, except perhaps with Browse whose code I argue should be part of the Sugar toolkit anyway. Consider that some stupid DOS program I wrote back in 1995 still works just fine on the Windows 7 Beta - that's some impressive binary compatibility. We don't have to go that far, we just have to maintain the DBus protocol for C (and eventually other) activities and the Sugar toolkit API for Python activities. -Wade ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity Versioning (Was Re: [RELEASE] Terminal v24)
On Wed, Mar 11, 2009 at 12:05 PM, Tomeu Vizoso to...@sugarlabs.org wrote: On Wed, Mar 11, 2009 at 17:00, Eben Eliason e...@laptop.org wrote: Here is some (OK, a lot) of background reading on the subject. I still cast my vote for a major/minor distinction, as mentioned in my response on the second thread below. http://www.mail-archive.com/de...@lists.laptop.org/msg11149.html http://www.mail-archive.com/su...@lists.laptop.org/msg03283.html That's also my favorite right now. I actually have the exact opposite instinct, coming at it from the user's perspective. The best choice for *users* is to keep the linearly incrementing version, and document which activity versions work with which Sugar versions. The activities.sugarlabs.org system already has an easy way to see what application versions an activity version works with. We should strive to ensure that newer versions of activities will work with older versions of Sugar or else fail gracefully. Eben's idea to show activity startup failure information on the launcher screen would help a lot with the fail gracefully part. Being able to branch activities would perhaps help the Sugar development team. But for the users, in this situation it would be best to make a new Terminal 25 that works with 0.86 and 0.84, and then update 0.84 to reference that. Think about it this way- someone with 0.84 can go *right now* and download Terminal v24 or later. So why can't we just update 0.84 to reference Terminal v24+ if a bug is found in v23? Regards, Wade ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity Versioning (Was Re: [RELEASE] Terminal v24)
On Wed, Mar 11, 2009 at 1:05 PM, Wade Brainerd wad...@gmail.com wrote: On Wed, Mar 11, 2009 at 12:05 PM, Tomeu Vizoso to...@sugarlabs.org wrote: On Wed, Mar 11, 2009 at 17:00, Eben Eliason e...@laptop.org wrote: Here is some (OK, a lot) of background reading on the subject. I still cast my vote for a major/minor distinction, as mentioned in my response on the second thread below. http://www.mail-archive.com/de...@lists.laptop.org/msg11149.html http://www.mail-archive.com/su...@lists.laptop.org/msg03283.html That's also my favorite right now. I actually have the exact opposite instinct, coming at it from the user's perspective. The best choice for *users* is to keep the linearly incrementing version, and document which activity versions work with which Sugar versions. The activities.sugarlabs.org system already has an easy way to see what application versions an activity version works with. We should strive to ensure that newer versions of activities will work with older versions of Sugar or else fail gracefully. Eben's idea to I think this might be a big assumption to make. Sugar could include new libraries at some point. We could add additional classes and controls to the toolkit. There could be a fundamental change in the protocol for some activity or service. Obviously we'd prefer to keep backward compatibility, but can we promise it always and indefinitely? show activity startup failure information on the launcher screen would help a lot with the fail gracefully part. If we wait until activity launch to inform the user a particular activity won't work for them, we'd better be quite certain that it's easy to revert the update. Being able to branch activities would perhaps help the Sugar development team. But for the users, in this situation it would be best to make a new Terminal 25 that works with 0.86 and 0.84, and then update 0.84 to reference that. Think about it this way- someone with 0.84 can go *right now* and download Terminal v24 or later. So why can't we just update 0.84 to reference Terminal v24+ if a bug is found in v23? This could be ideal if every newer version will always work with older versions of Sugar. Consider, though, that some bugs might only exist on older versions of Sugar. Would we want to push an update to everyone for this? Also, it still seems clearest to me to be able to make statements like versions 21–23 of Terminal work on 0.84 and version 24 works on 0.86 (where versions have one or more implicit .x minor versions). With the major-version-only approach (and assuming we don't have full backward compatibility), we have to resort to statements like versions 21–23 and also 25 work on 0.84, and versions 24 and 26 work on 0.86. - Eben Regards, Wade ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity Versioning (Was Re: [RELEASE] Terminal v24)
On Wed, Mar 11, 2009 at 1:17 PM, Eben Eliason e...@laptop.org wrote: On Wed, Mar 11, 2009 at 1:05 PM, Wade Brainerd wad...@gmail.com wrote: On Wed, Mar 11, 2009 at 12:05 PM, Tomeu Vizoso to...@sugarlabs.org wrote: On Wed, Mar 11, 2009 at 17:00, Eben Eliason e...@laptop.org wrote: Here is some (OK, a lot) of background reading on the subject. I still cast my vote for a major/minor distinction, as mentioned in my response on the second thread below. http://www.mail-archive.com/de...@lists.laptop.org/msg11149.html http://www.mail-archive.com/su...@lists.laptop.org/msg03283.html That's also my favorite right now. I actually have the exact opposite instinct, coming at it from the user's perspective. The best choice for *users* is to keep the linearly incrementing version, and document which activity versions work with which Sugar versions. The activities.sugarlabs.org system already has an easy way to see what application versions an activity version works with. We should strive to ensure that newer versions of activities will work with older versions of Sugar or else fail gracefully. Eben's idea to I think this might be a big assumption to make. Sugar could include new libraries at some point. We could add additional classes and controls to the toolkit. There could be a fundamental change in the protocol for some activity or service. Obviously we'd prefer to keep backward compatibility, but can we promise it always and indefinitely? show activity startup failure information on the launcher screen would help a lot with the fail gracefully part. If we wait until activity launch to inform the user a particular activity won't work for them, we'd better be quite certain that it's easy to revert the update. Being able to branch activities would perhaps help the Sugar development team. But for the users, in this situation it would be best to make a new Terminal 25 that works with 0.86 and 0.84, and then update 0.84 to reference that. Think about it this way- someone with 0.84 can go *right now* and download Terminal v24 or later. So why can't we just update 0.84 to reference Terminal v24+ if a bug is found in v23? This could be ideal if every newer version will always work with older versions of Sugar. Consider, though, that some bugs might only exist on older versions of Sugar. Would we want to push an update to everyone for this? Also, it still seems clearest to me to be able to make statements like versions 21–23 of Terminal work on 0.84 and version 24 works on 0.86 (where versions have one or more implicit .x minor versions). With the major-version-only approach (and assuming we don't have full backward compatibility), we have to resort to statements like versions 21–23 and also 25 work on 0.84, and versions 24 and 26 work on 0.86. - Eben Regards, Wade Ultimately I think this all comes down to putting the responsibility for stability and compatibility on the developer instead of the user. As soon as we add those minor numbers, people's eyes will glaze over and the support emails will start rolling in :) If the Sugar developers are responsible about keeping the API compatible, and if Activity developers are responsible about responding to bug reports and maintaining compatibility, the situation you are describing will not happen. Generally speaking we are talking about theoretical exceptions here anyway - I can't think of a situation where it's actually happened, except perhaps with Browse whose code I argue should be part of the Sugar toolkit anyway. Consider that some stupid DOS program I wrote back in 1995 still works just fine on the Windows 7 Beta - that's some impressive binary compatibility. We don't have to go that far, we just have to maintain the DBus protocol for C (and eventually other) activities and the Sugar toolkit API for Python activities. -Wade ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
