Re: [Sugar-devel] Activity Versioning - Dotted Scheme
On Sun, Dec 6, 2009 at 01:42, Aleksey Lim alsr...@member.fsf.org wrote: On Wed, Dec 02, 2009 at 04:38:56PM +0100, Bert Freudenberg wrote: On 30.11.2009, at 21:24, Bert Freudenberg wrote: On 30.11.2009, at 20:02, Aleksey Lim wrote: On Mon, Nov 30, 2009 at 07:49:15PM +0100, Simon Schampijer wrote: On 11/30/2009 10:00 AM, Bert Freudenberg wrote: On 29.11.2009, at 20:50, Simon Schampijer wrote: Well, if an activity will work for an older release is not only determined by the activity version number. For example, activities that moved to the new toolbar design are not working for older releases 0.86. I don't think we can always avoid breaking backwards compatibility. But so far we have managed to make is at least *possible* for an activity author to have a single activity version run under all Sugar versions. This would be the first instance where the author would not have that chance. I'm pretty sure we can find a scheme that both allows a single activity bundle to provide dotted version numbers for new Sugar, but keep working in old Sugar. E.g., we do not have to re-use the activity_version field if that breaks the parsing in older versions. It could be a new field named dotted_activity_version or simply version or something else. An activity author who cared could then provide both, a decimal and a dotted activity version. - Bert - Sorry, for the mixup. Yes we could add a way for the dotted version number, and your idea sounds good. How does Bert's idea from above sounds to others? +1, but maybe use activity_release(or so) instead of dotted_activity_version, the full version in 0.88+ will be activity_version.activity_release? That would link the old and new version field - I thought of them as being independent. Basically, the old activity_version field would be a like a build number, increasing for every build, as we did before. It would be optional in Sugar 0.88. The real user-visible version number would be the dotted one in a different field. An activity author who wants to support both could keep incrementing activity_version, and assign dotted version numbers independently. - Bert - Thinking about this, for Etoys it doesn't really make a difference. We can as well switch to the dotted-only scheme. So unless other activity authors feel backwards compatibility is needed, just use whatever is simplest. Is this already written up as a feature? Couldn't find it. I've created http://wiki.sugarlabs.org/go/Features/Dotted_Activity_Versions and wrote several options of your proposal(how I understood it) in http://wiki.sugarlabs.org/go/Features/Dotted_Activity_Versions#Detailed_Description Also I pushed it to Feature Ready for Release Manager group though this feature doesn't meet all requirements(there is no owner, I guess it will be trivial to code it) but it let us do not forget about this feature. Thanks a lot for entering the feature page. Do we have any consensus on which alternative is best? Regards, Tomeu -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity Versioning - Dotted Scheme
On Mon, Dec 14, 2009 at 01:23:47PM -0200, Tomeu Vizoso wrote: On Sun, Dec 6, 2009 at 01:42, Aleksey Lim alsr...@member.fsf.org wrote: On Wed, Dec 02, 2009 at 04:38:56PM +0100, Bert Freudenberg wrote: On 30.11.2009, at 21:24, Bert Freudenberg wrote: On 30.11.2009, at 20:02, Aleksey Lim wrote: On Mon, Nov 30, 2009 at 07:49:15PM +0100, Simon Schampijer wrote: On 11/30/2009 10:00 AM, Bert Freudenberg wrote: On 29.11.2009, at 20:50, Simon Schampijer wrote: Well, if an activity will work for an older release is not only determined by the activity version number. For example, activities that moved to the new toolbar design are not working for older releases 0.86. I don't think we can always avoid breaking backwards compatibility. But so far we have managed to make is at least *possible* for an activity author to have a single activity version run under all Sugar versions. This would be the first instance where the author would not have that chance. I'm pretty sure we can find a scheme that both allows a single activity bundle to provide dotted version numbers for new Sugar, but keep working in old Sugar. E.g., we do not have to re-use the activity_version field if that breaks the parsing in older versions. It could be a new field named dotted_activity_version or simply version or something else. An activity author who cared could then provide both, a decimal and a dotted activity version. - Bert - Sorry, for the mixup. Yes we could add a way for the dotted version number, and your idea sounds good. How does Bert's idea from above sounds to others? +1, but maybe use activity_release(or so) instead of dotted_activity_version, the full version in 0.88+ will be activity_version.activity_release? That would link the old and new version field - I thought of them as being independent. Basically, the old activity_version field would be a like a build number, increasing for every build, as we did before. It would be optional in Sugar 0.88. The real user-visible version number would be the dotted one in a different field. An activity author who wants to support both could keep incrementing activity_version, and assign dotted version numbers independently. - Bert - Thinking about this, for Etoys it doesn't really make a difference. We can as well switch to the dotted-only scheme. So unless other activity authors feel backwards compatibility is needed, just use whatever is simplest. Is this already written up as a feature? Couldn't find it. I've created http://wiki.sugarlabs.org/go/Features/Dotted_Activity_Versions and wrote several options of your proposal(how I understood it) in http://wiki.sugarlabs.org/go/Features/Dotted_Activity_Versions#Detailed_Description Also I pushed it to Feature Ready for Release Manager group though this feature doesn't meet all requirements(there is no owner, I guess it will be trivial to code it) but it let us do not forget about this feature. Thanks a lot for entering the feature page. Do we have any consensus on which alternative is best? I'm personally for 2nd option of http://wiki.sugarlabs.org/go/Features/Dotted_Activity_Versions#Detailed_Description Regards, Tomeu -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity Versioning - Dotted Scheme
Am 14.12.2009 um 16:26 schrieb Aleksey Lim: On Mon, Dec 14, 2009 at 01:23:47PM -0200, Tomeu Vizoso wrote: On Sun, Dec 6, 2009 at 01:42, Aleksey Lim alsr...@member.fsf.org wrote: On Wed, Dec 02, 2009 at 04:38:56PM +0100, Bert Freudenberg wrote: On 30.11.2009, at 21:24, Bert Freudenberg wrote: On 30.11.2009, at 20:02, Aleksey Lim wrote: On Mon, Nov 30, 2009 at 07:49:15PM +0100, Simon Schampijer wrote: On 11/30/2009 10:00 AM, Bert Freudenberg wrote: On 29.11.2009, at 20:50, Simon Schampijer wrote: Well, if an activity will work for an older release is not only determined by the activity version number. For example, activities that moved to the new toolbar design are not working for older releases 0.86. I don't think we can always avoid breaking backwards compatibility. But so far we have managed to make is at least *possible* for an activity author to have a single activity version run under all Sugar versions. This would be the first instance where the author would not have that chance. I'm pretty sure we can find a scheme that both allows a single activity bundle to provide dotted version numbers for new Sugar, but keep working in old Sugar. E.g., we do not have to re-use the activity_version field if that breaks the parsing in older versions. It could be a new field named dotted_activity_version or simply version or something else. An activity author who cared could then provide both, a decimal and a dotted activity version. - Bert - Sorry, for the mixup. Yes we could add a way for the dotted version number, and your idea sounds good. How does Bert's idea from above sounds to others? +1, but maybe use activity_release(or so) instead of dotted_activity_version, the full version in 0.88+ will be activity_version.activity_release? That would link the old and new version field - I thought of them as being independent. Basically, the old activity_version field would be a like a build number, increasing for every build, as we did before. It would be optional in Sugar 0.88. The real user-visible version number would be the dotted one in a different field. An activity author who wants to support both could keep incrementing activity_version, and assign dotted version numbers independently. - Bert - Thinking about this, for Etoys it doesn't really make a difference. We can as well switch to the dotted-only scheme. So unless other activity authors feel backwards compatibility is needed, just use whatever is simplest. Is this already written up as a feature? Couldn't find it. I've created http://wiki.sugarlabs.org/go/Features/Dotted_Activity_Versions and wrote several options of your proposal(how I understood it) in http://wiki.sugarlabs.org/go/Features/Dotted_Activity_Versions#Detailed_Description Also I pushed it to Feature Ready for Release Manager group though this feature doesn't meet all requirements(there is no owner, I guess it will be trivial to code it) but it let us do not forget about this feature. Thanks a lot for entering the feature page. Do we have any consensus on which alternative is best? I'm personally for 2nd option of http://wiki.sugarlabs.org/go/Features/Dotted_Activity_Versions#Detailed_Description Of the given ones I like the third option best now. The old Browse-105 would be treated by new Sugar as version 0.105. Then from Sugar 0.88 on we could start using a sane version scheme, so the a Browse would be 1.0 maybe. Activity authors who want to build bundles that work in older Sugar versions too would simply leave out the new dotted version field. = OTOH, is there a reason to restrict the version to a major.minor format? Couldn't it be pretty much free-form, like in distro packages? Then we would simply extend the allowed contents of the activity_version field. Activities that need to run in old Sugar versions would just continue to use integers only, others can switch to a more convenient scheme (and the upgrade logic would treat any integer as being older than any dotted number). This might solve the already foreseeable problem of future authors wanting to have more flexible versioning schemes. - Bert - ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity Versioning - Dotted Scheme
On Wed, Dec 02, 2009 at 04:38:56PM +0100, Bert Freudenberg wrote: On 30.11.2009, at 21:24, Bert Freudenberg wrote: On 30.11.2009, at 20:02, Aleksey Lim wrote: On Mon, Nov 30, 2009 at 07:49:15PM +0100, Simon Schampijer wrote: On 11/30/2009 10:00 AM, Bert Freudenberg wrote: On 29.11.2009, at 20:50, Simon Schampijer wrote: Well, if an activity will work for an older release is not only determined by the activity version number. For example, activities that moved to the new toolbar design are not working for older releases 0.86. I don't think we can always avoid breaking backwards compatibility. But so far we have managed to make is at least *possible* for an activity author to have a single activity version run under all Sugar versions. This would be the first instance where the author would not have that chance. I'm pretty sure we can find a scheme that both allows a single activity bundle to provide dotted version numbers for new Sugar, but keep working in old Sugar. E.g., we do not have to re-use the activity_version field if that breaks the parsing in older versions. It could be a new field named dotted_activity_version or simply version or something else. An activity author who cared could then provide both, a decimal and a dotted activity version. - Bert - Sorry, for the mixup. Yes we could add a way for the dotted version number, and your idea sounds good. How does Bert's idea from above sounds to others? +1, but maybe use activity_release(or so) instead of dotted_activity_version, the full version in 0.88+ will be activity_version.activity_release? That would link the old and new version field - I thought of them as being independent. Basically, the old activity_version field would be a like a build number, increasing for every build, as we did before. It would be optional in Sugar 0.88. The real user-visible version number would be the dotted one in a different field. An activity author who wants to support both could keep incrementing activity_version, and assign dotted version numbers independently. - Bert - Thinking about this, for Etoys it doesn't really make a difference. We can as well switch to the dotted-only scheme. So unless other activity authors feel backwards compatibility is needed, just use whatever is simplest. Is this already written up as a feature? Couldn't find it. I've created http://wiki.sugarlabs.org/go/Features/Dotted_Activity_Versions and wrote several options of your proposal(how I understood it) in http://wiki.sugarlabs.org/go/Features/Dotted_Activity_Versions#Detailed_Description Also I pushed it to Feature Ready for Release Manager group though this feature doesn't meet all requirements(there is no owner, I guess it will be trivial to code it) but it let us do not forget about this feature. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity Versioning - Dotted Scheme
On 30.11.2009, at 21:24, Bert Freudenberg wrote: On 30.11.2009, at 20:02, Aleksey Lim wrote: On Mon, Nov 30, 2009 at 07:49:15PM +0100, Simon Schampijer wrote: On 11/30/2009 10:00 AM, Bert Freudenberg wrote: On 29.11.2009, at 20:50, Simon Schampijer wrote: Well, if an activity will work for an older release is not only determined by the activity version number. For example, activities that moved to the new toolbar design are not working for older releases 0.86. I don't think we can always avoid breaking backwards compatibility. But so far we have managed to make is at least *possible* for an activity author to have a single activity version run under all Sugar versions. This would be the first instance where the author would not have that chance. I'm pretty sure we can find a scheme that both allows a single activity bundle to provide dotted version numbers for new Sugar, but keep working in old Sugar. E.g., we do not have to re-use the activity_version field if that breaks the parsing in older versions. It could be a new field named dotted_activity_version or simply version or something else. An activity author who cared could then provide both, a decimal and a dotted activity version. - Bert - Sorry, for the mixup. Yes we could add a way for the dotted version number, and your idea sounds good. How does Bert's idea from above sounds to others? +1, but maybe use activity_release(or so) instead of dotted_activity_version, the full version in 0.88+ will be activity_version.activity_release? That would link the old and new version field - I thought of them as being independent. Basically, the old activity_version field would be a like a build number, increasing for every build, as we did before. It would be optional in Sugar 0.88. The real user-visible version number would be the dotted one in a different field. An activity author who wants to support both could keep incrementing activity_version, and assign dotted version numbers independently. - Bert - Thinking about this, for Etoys it doesn't really make a difference. We can as well switch to the dotted-only scheme. So unless other activity authors feel backwards compatibility is needed, just use whatever is simplest. Is this already written up as a feature? Couldn't find it. - Bert - ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity Versioning - Dotted Scheme
On 29.11.2009, at 20:50, Simon Schampijer wrote: Well, if an activity will work for an older release is not only determined by the activity version number. For example, activities that moved to the new toolbar design are not working for older releases 0.86. I don't think we can always avoid breaking backwards compatibility. But so far we have managed to make is at least *possible* for an activity author to have a single activity version run under all Sugar versions. This would be the first instance where the author would not have that chance. I'm pretty sure we can find a scheme that both allows a single activity bundle to provide dotted version numbers for new Sugar, but keep working in old Sugar. E.g., we do not have to re-use the activity_version field if that breaks the parsing in older versions. It could be a new field named dotted_activity_version or simply version or something else. An activity author who cared could then provide both, a decimal and a dotted activity version. - Bert - ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity Versioning - Dotted Scheme
On 11/30/2009 10:00 AM, Bert Freudenberg wrote: On 29.11.2009, at 20:50, Simon Schampijer wrote: Well, if an activity will work for an older release is not only determined by the activity version number. For example, activities that moved to the new toolbar design are not working for older releases 0.86. I don't think we can always avoid breaking backwards compatibility. But so far we have managed to make is at least *possible* for an activity author to have a single activity version run under all Sugar versions. This would be the first instance where the author would not have that chance. I'm pretty sure we can find a scheme that both allows a single activity bundle to provide dotted version numbers for new Sugar, but keep working in old Sugar. E.g., we do not have to re-use the activity_version field if that breaks the parsing in older versions. It could be a new field named dotted_activity_version or simply version or something else. An activity author who cared could then provide both, a decimal and a dotted activity version. - Bert - Sorry, for the mixup. Yes we could add a way for the dotted version number, and your idea sounds good. How does Bert's idea from above sounds to others? My point was, that we do not have to be backwards compatible at all costs (this was a general assumption). Thanks, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity Versioning - Dotted Scheme
On Mon, Nov 30, 2009 at 07:49:15PM +0100, Simon Schampijer wrote: On 11/30/2009 10:00 AM, Bert Freudenberg wrote: On 29.11.2009, at 20:50, Simon Schampijer wrote: Well, if an activity will work for an older release is not only determined by the activity version number. For example, activities that moved to the new toolbar design are not working for older releases 0.86. I don't think we can always avoid breaking backwards compatibility. But so far we have managed to make is at least *possible* for an activity author to have a single activity version run under all Sugar versions. This would be the first instance where the author would not have that chance. I'm pretty sure we can find a scheme that both allows a single activity bundle to provide dotted version numbers for new Sugar, but keep working in old Sugar. E.g., we do not have to re-use the activity_version field if that breaks the parsing in older versions. It could be a new field named dotted_activity_version or simply version or something else. An activity author who cared could then provide both, a decimal and a dotted activity version. - Bert - Sorry, for the mixup. Yes we could add a way for the dotted version number, and your idea sounds good. How does Bert's idea from above sounds to others? +1, but maybe use activity_release(or so) instead of dotted_activity_version, the full version in 0.88+ will be activity_version.activity_release? My point was, that we do not have to be backwards compatible at all costs (this was a general assumption). Thanks, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity Versioning - Dotted Scheme
Aleksey Lim wrote: +1, but maybe use activity_release(or so) instead of dotted_activity_version, the full version in 0.88+ will be activity_version.activity_release? The standard term is minor version number, so minor_version seems appropriate. --Ben http://en.wikipedia.org/wiki/Software_versioning#Change_significance signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity Versioning - Dotted Scheme
On 30.11.2009, at 20:02, Aleksey Lim wrote: On Mon, Nov 30, 2009 at 07:49:15PM +0100, Simon Schampijer wrote: On 11/30/2009 10:00 AM, Bert Freudenberg wrote: On 29.11.2009, at 20:50, Simon Schampijer wrote: Well, if an activity will work for an older release is not only determined by the activity version number. For example, activities that moved to the new toolbar design are not working for older releases 0.86. I don't think we can always avoid breaking backwards compatibility. But so far we have managed to make is at least *possible* for an activity author to have a single activity version run under all Sugar versions. This would be the first instance where the author would not have that chance. I'm pretty sure we can find a scheme that both allows a single activity bundle to provide dotted version numbers for new Sugar, but keep working in old Sugar. E.g., we do not have to re-use the activity_version field if that breaks the parsing in older versions. It could be a new field named dotted_activity_version or simply version or something else. An activity author who cared could then provide both, a decimal and a dotted activity version. - Bert - Sorry, for the mixup. Yes we could add a way for the dotted version number, and your idea sounds good. How does Bert's idea from above sounds to others? +1, but maybe use activity_release(or so) instead of dotted_activity_version, the full version in 0.88+ will be activity_version.activity_release? That would link the old and new version field - I thought of them as being independent. Basically, the old activity_version field would be a like a build number, increasing for every build, as we did before. It would be optional in Sugar 0.88. The real user-visible version number would be the dotted one in a different field. An activity author who wants to support both could keep incrementing activity_version, and assign dotted version numbers independently. - Bert - ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity Versioning - Dotted Scheme
A problem with introducing dotted version numbers is that Sugar
versions 0.82-0.86 parse the activity version field using the Python
int() function.
a = int('100.3')
Traceback (most recent call last):
File stdin, line 1, in module
ValueError: invalid literal for int() with base 10: '100.3'
If we introduce periods into activity version strings, Sugar will
throw a MalformedBundleException when parsing activity.info. The
effect would be that Sugar would simply fail to register the activity;
it would not appear in the Home view etc.
So, introducing period syntax into an activity bundle automatically
makes it incompatible with Sugar versions 0.82 - 0.86.
This is too harsh for me, so like Gary I would just keep using integers.
On Tue, Nov 24, 2009 at 8:54 AM, Aleksey Lim alsr...@member.fsf.org wrote:
Yes, good point. We should revisit the current activities in Fructose
and think if it makes sense to keep them in Fructose. As you said, one
point is if an activity has dependencies on the platform itself like
Browse (Hulahop).
Has anyone looked into what would be needed to just make Browse work
with older versions of Hulahop?
Anecdote: My XO ran out of space over Thanksgiving and automatically
deleted Browse at boot time. I downloaded the latest version, but it
failed to launch as my XO is running the OLPC 8.2.0 build. This was
pretty annoying to me as I didn't have a web browser available to go
find out which version *would* work.
In mind thats wrong way, some activities have non-sugar SP dependencies
and can work fine with several SP releases, I guess its better to not add
additioanl complexity and use only one source for compatibility info -
on ASLO(moreove we have fructose activities on ASLO).
+1 to keeping activity version numbers totally separate from SP version.
BTW for 0.88 can exclude fructose from core packages at all and let
deployers decide what should be included to deployments.
I support this - ASLO works well enough that Fructose isn't strictly needed.
Wade
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity Versioning - Dotted Scheme
On 11/29/2009 07:23 PM, Wade Brainerd wrote:
A problem with introducing dotted version numbers is that Sugar
versions 0.82-0.86 parse the activity version field using the Python
int() function.
a = int('100.3')
Traceback (most recent call last):
File stdin, line 1, inmodule
ValueError: invalid literal for int() with base 10: '100.3'
If we introduce periods into activity version strings, Sugar will
throw a MalformedBundleException when parsing activity.info. The
effect would be that Sugar would simply fail to register the activity;
it would not appear in the Home view etc.
So, introducing period syntax into an activity bundle automatically
makes it incompatible with Sugar versions 0.82 - 0.86.
This is too harsh for me, so like Gary I would just keep using integers.
Well, if an activity will work for an older release is not only
determined by the activity version number. For example, activities that
moved to the new toolbar design are not working for older releases
0.86. I don't think we can always avoid breaking backwards compatibility.
As Aleksey stated, it is good to keep the dependencies at one place:
ASLO does this now (for the users that use it to install and update
activities).
If we conclude to remove Fructose, I guess the major-minor version
numbers makes only sense technically - easier to differentiate between
minor and major changes.
Regards,
Simon
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity Versioning - Dotted Scheme
On Sun, Nov 29, 2009 at 01:23:22PM -0500, Wade Brainerd wrote: Anecdote: My XO ran out of space over Thanksgiving and automatically deleted Browse at boot time. I downloaded the latest version, but it failed to launch as my XO is running the OLPC 8.2.0 build. This was pretty annoying to me as I didn't have a web browser available to go find out which version *would* work. Hmmm - I believe we were promised that ASLO would ensure that only Activities supported by the client branch of Sugar would be served. Was that a brain fart of mine, a single glitch in an otherwise reliable ASLO version handling, or whould we simply warn Sugar 0.82 users to *not* use ASLO? - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity Versioning - Dotted Scheme
On Sun, Nov 29, 2009 at 3:28 PM, Jonas Smedegaard d...@jones.dk wrote: On Sun, Nov 29, 2009 at 01:23:22PM -0500, Wade Brainerd wrote: Anecdote: My XO ran out of space over Thanksgiving and automatically deleted Browse at boot time. I downloaded the latest version, but it failed to launch as my XO is running the OLPC 8.2.0 build. This was pretty annoying to me as I didn't have a web browser available to go find out which version *would* work. Hmmm - I believe we were promised that ASLO would ensure that only Activities supported by the client branch of Sugar would be served. Was that a brain fart of mine, a single glitch in an otherwise reliable ASLO version handling, or whould we simply warn Sugar 0.82 users to *not* use ASLO? ASLO does that by checking for the Browse user agent - in my situation, I had to use scp to download Browse from download.sugarlabs.org. Still, the latest Browse is only about 3400 lines of Python code - I wonder how hard it would be to make it backwards compatible with 0.82. Wade ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity Versioning - Dotted Scheme
On Sun, Nov 29, 2009 at 03:38:26PM -0500, Wade Brainerd wrote: On Sun, Nov 29, 2009 at 3:28 PM, Jonas Smedegaard d...@jones.dk wrote: On Sun, Nov 29, 2009 at 01:23:22PM -0500, Wade Brainerd wrote: Anecdote: My XO ran out of space over Thanksgiving and automatically deleted Browse at boot time. I downloaded the latest version, but it failed to launch as my XO is running the OLPC 8.2.0 build. This was pretty annoying to me as I didn't have a web browser available to go find out which version *would* work. Hmmm - I believe we were promised that ASLO would ensure that only Activities supported by the client branch of Sugar would be served. Was that a brain fart of mine, a single glitch in an otherwise reliable ASLO version handling, or whould we simply warn Sugar 0.82 users to *not* use ASLO? ASLO does that by checking for the Browse user agent - in my situation, I had to use scp to download Browse from download.sugarlabs.org. Ahh, makes sense then :-) Still, the latest Browse is only about 3400 lines of Python code - I wonder how hard it would be to make it backwards compatible with 0.82. I'll leave that to the real programmers :-) - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity Versioning - Dotted Scheme
On Sun, Nov 29, 2009 at 3:05 PM, Jonas Smedegaard d...@jones.dk wrote: On Sun, Nov 29, 2009 at 03:38:26PM -0500, Wade Brainerd wrote: On Sun, Nov 29, 2009 at 3:28 PM, Jonas Smedegaard d...@jones.dk wrote: On Sun, Nov 29, 2009 at 01:23:22PM -0500, Wade Brainerd wrote: Anecdote: My XO ran out of space over Thanksgiving and automatically deleted Browse at boot time. I downloaded the latest version, but it failed to launch as my XO is running the OLPC 8.2.0 build. This was pretty annoying to me as I didn't have a web browser available to go find out which version *would* work. Hmmm - I believe we were promised that ASLO would ensure that only Activities supported by the client branch of Sugar would be served. Was that a brain fart of mine, a single glitch in an otherwise reliable ASLO version handling, or whould we simply warn Sugar 0.82 users to *not* use ASLO? ASLO does that by checking for the Browse user agent - in my situation, I had to use scp to download Browse from download.sugarlabs.org. Ahh, makes sense then :-) Still, the latest Browse is only about 3400 lines of Python code - I wonder how hard it would be to make it backwards compatible with 0.82. I'll leave that to the real programmers :-) The other side of the equation depends on activity developers and editors testing their activities on the versions they identify as working on ASLO. I believe that the next batch of XO1.5s will continue to update from wiki.laptop.org over concern about developers correctly marking activity compatibility. david - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQIcBAEBCgAGBQJLEuIhAAoJECx8MUbBoAEhhS4P/i3ImrYwKVar/OrD0dcEPtwL pOD1Z3X+p/CYjQcIqozmlh98pBGZrYW0jonYJU5500NzC0upn9kF3N6AzUSACkCe FgiFp++hIZfaGwp0qR/XC9GoXESjkqI7h70mVEntyhmmhrTWasy91uyx1S+5fJ1z poyH14yB/8i7/YbZZxd6cGyrsXP+winO+3478zBjt0mKOaUDYI4n/Wn85HmBkzlJ VrL2MEnN7NYLSg2Hr7sdUtF4RYr7vHKS0vTsHltXgzSQws84U5WF8Oz1vNvDpP+e p4mQYB7hgSXVgxUVTvVFUo00kL13VDN89PNhev77NkzUoffw1VdzyeBApje1HnGj uL+t9RvreP61E434SHHeEvQXwPYhvbf03e9Gv1EflGTUBtHCVRGsgNO6uqkjO0j0 rLwFyanMDleeM3YOiBNda7a0k4psx3ZfrGSiGRx4DiGcZwFwjvQnoiKiwC6JEYMr rp8WS8FD4glcHx4L6aJNINcb9hiHpTJd8fF5vqTJKXbakgIjVvuUxkCiZMgqgG69 LT66UIeUoS7AjoWN1Hxre7hZ96O7qMCHvkErJHeyfopgVD0nlf52E/LDLTAgSLVp YapJSqfNiqZUVLTPedHF0QRayPz04h/qtb9vNgl16jS6wz2aFwxErWh0CIGOo2sH Q0JIwGQJ9wQU/gOZ/L0c =b1Zt -END PGP SIGNATURE- ___ 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
[Sugar-devel] Activity Versioning - Dotted Scheme
Hi, as a follow up on an older thread: http://lists.sugarlabs.org/archive/sugar-devel/2009-October/019939.html - we want to get the versioning sorted in 0.88 for real. So far we came up with these three options: a) The release cycle dependent one: Activities name their activity after the Sugar version they are developed against. If it was released during the 0.88 cycle and developed against 0.88, then it would be 0.88.x. b) MAJOR.MINOR (x.y): The new Browse activity for 0.88 would be 115.0. Fixes would go into 115.1, 115.2... c) MAJOR.MINOR.PATCH (x.y.z) The new Browse activity for 0.88 would be 115.0.0. Fixes would go into 115.1.0, 115.2.1... What do people like best? Thanks, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity Versioning - Dotted Scheme
Hi Simon, On 24 Nov 2009, at 11:20, Simon Schampijer wrote: Hi, as a follow up on an older thread: http://lists.sugarlabs.org/archive/sugar-devel/2009-October/019939.html - we want to get the versioning sorted in 0.88 for real. So far we came up with these three options: a) The release cycle dependent one: Activities name their activity after the Sugar version they are developed against. If it was released during the 0.88 cycle and developed against 0.88, then it would be 0.88.x. Should we also try and resolve the Fructose issue as well here? Is Fructose just a random grab bag of demo activities, or is it the set of activities that are dependant on a single specific release of Glucose? Right now it contains a mix of both. I'd be against including Sugar version numbers in activity version number (unless perhaps they fail to work in other sugar releases). Activity development should be as far removed from the Glucose development cycle as is feasibly possible. If Fructose becomes the set of Glucose dependent activities (like Browse), they could be the only ones that require special versioning support b) MAJOR.MINOR (x.y): The new Browse activity for 0.88 would be 115.0. Fixes would go into 115.1, 115.2... Yes, seems simple enough, but only if/when you have to support an activity that has to fork compatibility between Sugar releases. c) MAJOR.MINOR.PATCH (x.y.z) The new Browse activity for 0.88 would be 115.0.0. Fixes would go into 115.1.0, 115.2.1... Not sure this adds much to the above major.minor option. What do people like best? We need to keep in mind not breaking existing deployments. If I have to start releasing Moon-11.0.xo, Moon-11.1.xo, Moon-11.2.xo, I'd be really annoyed/frustrated if this broke things for our current user base – so I guess that means I'll be sticking with integer version numbers for all my activity work in the foreseeable future, which ever way this goes. Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity Versioning - Dotted Scheme
Hi Simon, a) The release cycle dependent one: Activities name their activity after the Sugar version they are developed against. If it was released during the 0.88 cycle and developed against 0.88, then it would be 0.88.x. I don't think it is a good idea that activities are developed against a specific version of Sugar. For example, right now in Uruguay we have 400.000 laptops with version 0.82. Updating to a new version is a very complex logistic problem. (Besides, as far as I know there is no XO image ready with a newer version of Sugar yet.) Legacy support can be painful but I think it is necessary. My wish is that as a rule all activities should be compatible with previous versions of Sugar and the Sugar API should try to remain as stable as possible. Regards, Gabriel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity Versioning - Dotted Scheme
On Tue, Nov 24, 2009 at 12:20:15PM +0100, Simon Schampijer wrote: Hi, as a follow up on an older thread: http://lists.sugarlabs.org/archive/sugar-devel/2009-October/019939.html - we want to get the versioning sorted in 0.88 for real. So far we came up with these three options: a) The release cycle dependent one: Activities name their activity after the Sugar version they are developed against. If it was released during the 0.88 cycle and developed against 0.88, then it would be 0.88.x. Most of activities are compatible with several release cycles, so using SP in activity versions adds only confusing b) MAJOR.MINOR (x.y): The new Browse activity for 0.88 would be 115.0. Fixes would go into 115.1, 115.2... c) MAJOR.MINOR.PATCH (x.y.z) The new Browse activity for 0.88 would be 115.0.0. Fixes would go into 115.1.0, 115.2.1... What do people like best? Thanks, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity Versioning - Dotted Scheme
On 11/24/2009 01:42 PM, Gary C Martin wrote: Hi Simon, On 24 Nov 2009, at 11:20, Simon Schampijer wrote: Hi, as a follow up on an older thread: http://lists.sugarlabs.org/archive/sugar-devel/2009-October/019939.html - we want to get the versioning sorted in 0.88 for real. So far we came up with these three options: a) The release cycle dependent one: Activities name their activity after the Sugar version they are developed against. If it was released during the 0.88 cycle and developed against 0.88, then it would be 0.88.x. Ok, I do not like that option neither. And the people that have replied, do not neither. Should we also try and resolve the Fructose issue as well here? Is Fructose just a random grab bag of demo activities, or is it the set of activities that are dependant on a single specific release of Glucose? Right now it contains a mix of both. I'd be against including Sugar version numbers in activity version number (unless perhaps they fail to work in other sugar releases). Activity development should be as far removed from the Glucose development cycle as is feasibly possible. If Fructose becomes the set of Glucose dependent activities (like Browse), they could be the only ones that require special versioning support Yes, good point. We should revisit the current activities in Fructose and think if it makes sense to keep them in Fructose. As you said, one point is if an activity has dependencies on the platform itself like Browse (Hulahop). I propose to go through all Fructose activities and see which one makes sense to keep in Fructose. b) MAJOR.MINOR (x.y): The new Browse activity for 0.88 would be 115.0. Fixes would go into 115.1, 115.2... Yes, seems simple enough, but only if/when you have to support an activity that has to fork compatibility between Sugar releases. Personally, I like this option best, for activities that needs that functionality (fructose mainly). c) MAJOR.MINOR.PATCH (x.y.z) The new Browse activity for 0.88 would be 115.0.0. Fixes would go into 115.1.0, 115.2.1... Not sure this adds much to the above major.minor option. What do people like best? We need to keep in mind not breaking existing deployments. If I have to start releasing Moon-11.0.xo, Moon-11.1.xo, Moon-11.2.xo, I'd be really annoyed/frustrated if this broke things for our current user base – so I guess that means I'll be sticking with integer version numbers for all my activity work in the foreseeable future, which ever way this goes. If we stick with option b, you would still be able to just use an integer. Internally in 0.88 it is just represented as a float (e.g. 10 - 10.0), but it allows for the activity to use a dotted scheme if necessary. Thanks, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity Versioning - Dotted Scheme
On 11/24/2009 02:00 PM, Gabriel Eirea wrote: Hi Simon, a) The release cycle dependent one: Activities name their activity after the Sugar version they are developed against. If it was released during the 0.88 cycle and developed against 0.88, then it would be 0.88.x. I don't think it is a good idea that activities are developed against a specific version of Sugar. For example, right now in Uruguay we have 400.000 laptops with version 0.82. Updating to a new version is a very complex logistic problem. (Besides, as far as I know there is no XO image ready with a newer version of Sugar yet.) Legacy support can be painful but I think it is necessary. My wish is that as a rule all activities should be compatible with previous versions of Sugar and the Sugar API should try to remain as stable as possible. Regards, Gabriel Of course, it makes sense to minimize dependencies wherever possible, and the API should try to stay as much stable as possible. Though changes like the new toolbar design must happen at some points. And of course having a lot of glue code is costly, too. For the versioning, I like the mayor-minor scheme best. Is easily added and people can keep the integer versioning if they like. Regards, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity Versioning - Dotted Scheme
On 11/24/2009 02:12 PM, Aleksey Lim wrote: On Tue, Nov 24, 2009 at 12:20:15PM +0100, Simon Schampijer wrote: Hi, as a follow up on an older thread: http://lists.sugarlabs.org/archive/sugar-devel/2009-October/019939.html - we want to get the versioning sorted in 0.88 for real. So far we came up with these three options: a) The release cycle dependent one: Activities name their activity after the Sugar version they are developed against. If it was released during the 0.88 cycle and developed against 0.88, then it would be 0.88.x. Most of activities are compatible with several release cycles, so using SP in activity versions adds only confusing Yup, agreed. Thanks, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity Versioning - Dotted Scheme
On Tue, Nov 24, 2009 at 02:21:09PM +0100, Simon Schampijer wrote: On 11/24/2009 01:42 PM, Gary C Martin wrote: Hi Simon, On 24 Nov 2009, at 11:20, Simon Schampijer wrote: Hi, as a follow up on an older thread: http://lists.sugarlabs.org/archive/sugar-devel/2009-October/019939.html - we want to get the versioning sorted in 0.88 for real. So far we came up with these three options: a) The release cycle dependent one: Activities name their activity after the Sugar version they are developed against. If it was released during the 0.88 cycle and developed against 0.88, then it would be 0.88.x. Ok, I do not like that option neither. And the people that have replied, do not neither. Should we also try and resolve the Fructose issue as well here? Is Fructose just a random grab bag of demo activities, or is it the set of activities that are dependant on a single specific release of Glucose? Right now it contains a mix of both. I'd be against including Sugar version numbers in activity version number (unless perhaps they fail to work in other sugar releases). Activity development should be as far removed from the Glucose development cycle as is feasibly possible. If Fructose becomes the set of Glucose dependent activities (like Browse), they could be the only ones that require special versioning support Yes, good point. We should revisit the current activities in Fructose and think if it makes sense to keep them in Fructose. As you said, one point is if an activity has dependencies on the platform itself like Browse (Hulahop). In mind thats wrong way, some activities have non-sugar SP dependencies and can work fine with several SP releases, I guess its better to not add additioanl complexity and use only one source for compatibility info - on ASLO(moreove we have fructose activities on ASLO). BTW for 0.88 can exclude fructose from core packages at all and let deployers decide what should be included to deployments. I propose to go through all Fructose activities and see which one makes sense to keep in Fructose. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
