Re: [Sugar-devel] Namespace for 0.84 updates to Browse and Chat?
On Tue, Oct 13, 2009 at 01:48:10PM -0400, Wade Brainerd wrote: On Tue, Oct 13, 2009 at 1:38 PM, Tomeu Vizoso wrote: Is there some reason that we are forced to patch Browse and Chat such? Are newer versions of the activities not backwards compatible with older versions of Sugar? I believe that newer Browse rely on features of the Python hulahop library not available in older releases, without fallback :-( Don't know if the same is the case with Chat. - 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] Namespace for 0.84 updates to Browse and Chat?
On Tue, Oct 13, 2009 at 06:38:48PM +0100, Tomeu Vizoso wrote: On Tue, Oct 13, 2009 at 18:23, Jonas Smedegaard wrote: On Tue, Oct 13, 2009 at 04:06:08PM +0100, Tomeu Vizoso wrote: - start the dotted series from the last integer used: Browse-112.1, Browse-112.2, etc (ugly). No, I do not see it as ugly at all. Only if looking at the version numbers with marketing goggles on can I imagine it looking ugly: Version numbers simply reflects versions, that's all. Maybe I should have written confusing instead of ugly, meaning that people have some expectations of what version numbers mean and may not be aware of what happened in this case. Not sure I understand. You worry that users will find it confusing whether version 112 or 112.1 is newest? Then perhaps encourage the activity author to bump major version the first time minro version is introduced (completely unneeded technically, only for possible easier perception), like this: 111 → 112 → 113.1 → 113.2 etc. Remains to see what existing versions of Sugar would do with a bundle with a dot in the version number. Which was (if I recall correctly) my reason for wondering why you postpone for 0.88: that would only solve the issue for that newer release, not older deployments. Kind regards, - 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] Namespace for 0.84 updates to Browse and Chat?
On Tue, Oct 13, 2009 at 1:38 PM, Tomeu Vizoso wrote: > Remains to see what existing versions of Sugar would do with a bundle > with a dot in the version number. > It's parsed as int(version) [1] - so it's not going to work well! Is there some reason that we are forced to patch Browse and Chat such? Are newer versions of the activities not backwards compatible with older versions of Sugar? I think it's best if we can avoid user confusion as much as possible; especially given parallel sources of activities: apt-get, the activity updater, ASLO, etc. Best, Wade [1] http://git.sugarlabs.org/projects/sugar-toolkit/repos/mainline/blobs/master/src/sugar/bundle/activitybundle.py#line187 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Namespace for 0.84 updates to Browse and Chat?
On Tue, Oct 13, 2009 at 18:23, Jonas Smedegaard wrote: > On Tue, Oct 13, 2009 at 04:06:08PM +0100, Tomeu Vizoso wrote: >> >> On Fri, Oct 2, 2009 at 13:28, Jonas Smedegaard wrote: >>> >>> Hi Tomeu (and others), >>> >>> On Wed, Sep 30, 2009 at 06:48:05PM +0100, Tomeu Vizoso wrote: sorry for the late reply, this is a very good question. I think we should move to dotted version numbers for activities in 0.88, maybe interpreting a version number without a dot as 0.xx. For now and for your specific use case, what about preppending 0.84/0.86 to the activity version number? >>> >>> Debian supports resetting version numbers, but it may cause problems for >>> other distributions if Sugarlabs start releasing new packages with _lower_ >>> version numbers than the older ones. >>> >>> As an example, are you sure that your Mozilla web interface supports >>> resetting version numbers? Do the install mechanisms in Sugar itself? >> >> Yes, that's why I'm suggesting doing it for 0.88, so we have time to patch >> whatever needs to be patched. >> >> About newer activity versions with dotted version numbers not updating >> older ones in <=0.86 because they are interpreted as older, I guess we have >> three options: >> >> - accept it as-is, activity authors that want older versions of Sugar >> to update to their bundles need to also produce bundles with undotted >> version numbers (messy), >> >> - patch older versions to recognize the new scheme (won't be possible >> for many/most deployments), >> >> - start the dotted series from the last integer used: Browse-112.1, >> Browse-112.2, etc (ugly). >> >> Any better options? > > > Only option sane to me is your last one: Start using the classical > major[.minor[.micro]] version scheme, treating the older versions as being > purely a major number. > > No, I do not see it as ugly at all. Only if looking at the version numbers > with marketing goggles on can I imagine it looking ugly: Version numbers > simply reflects versions, that's all. > > If you want something technically ugly, then implement "epoch" handling in > version handling code everywhere with e.g. following notation (inspired by > Debian syntax): [epoch:]major[.minor[.micro]], bump packages to a new epoch > e.g. 111 → 112→ 1:2.0 → 1:2.1 etc. > > With such technically ugly approach you can have a marketing nice look by > stripping off epoch from GUI display of version numbers (but beware, users > will need to see the full true ugly version number somehow, to understand > why 2.0 is newer than 112!). Maybe I should have written confusing instead of ugly, meaning that people have some expectations of what version numbers mean and may not be aware of what happened in this case. Remains to see what existing versions of Sugar would do with a bundle with a dot in the version number. 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] Namespace for 0.84 updates to Browse and Chat?
On Tue, Oct 13, 2009 at 04:06:08PM +0100, Tomeu Vizoso wrote: On Fri, Oct 2, 2009 at 13:28, Jonas Smedegaard wrote: Hi Tomeu (and others), On Wed, Sep 30, 2009 at 06:48:05PM +0100, Tomeu Vizoso wrote: sorry for the late reply, this is a very good question. I think we should move to dotted version numbers for activities in 0.88, maybe interpreting a version number without a dot as 0.xx. For now and for your specific use case, what about preppending 0.84/0.86 to the activity version number? Debian supports resetting version numbers, but it may cause problems for other distributions if Sugarlabs start releasing new packages with _lower_ version numbers than the older ones. As an example, are you sure that your Mozilla web interface supports resetting version numbers? Do the install mechanisms in Sugar itself? Yes, that's why I'm suggesting doing it for 0.88, so we have time to patch whatever needs to be patched. About newer activity versions with dotted version numbers not updating older ones in <=0.86 because they are interpreted as older, I guess we have three options: - accept it as-is, activity authors that want older versions of Sugar to update to their bundles need to also produce bundles with undotted version numbers (messy), - patch older versions to recognize the new scheme (won't be possible for many/most deployments), - start the dotted series from the last integer used: Browse-112.1, Browse-112.2, etc (ugly). Any better options? Only option sane to me is your last one: Start using the classical major[.minor[.micro]] version scheme, treating the older versions as being purely a major number. No, I do not see it as ugly at all. Only if looking at the version numbers with marketing goggles on can I imagine it looking ugly: Version numbers simply reflects versions, that's all. If you want something technically ugly, then implement "epoch" handling in version handling code everywhere with e.g. following notation (inspired by Debian syntax): [epoch:]major[.minor[.micro]], bump packages to a new epoch e.g. 111 → 112→ 1:2.0 → 1:2.1 etc. With such technically ugly approach you can have a marketing nice look by stripping off epoch from GUI display of version numbers (but beware, users will need to see the full true ugly version number somehow, to understand why 2.0 is newer than 112!). Kind regards, - 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] Namespace for 0.84 updates to Browse and Chat?
On Fri, Oct 2, 2009 at 13:28, Jonas Smedegaard wrote: > Hi Tomeu (and others), > > On Wed, Sep 30, 2009 at 06:48:05PM +0100, Tomeu Vizoso wrote: >> >> sorry for the late reply, this is a very good question. >> >> I think we should move to dotted version numbers for activities in 0.88, >> maybe interpreting a version number without a dot as 0.xx. >> >> For now and for your specific use case, what about preppending 0.84/0.86 >> to the activity version number? > > Debian supports resetting version numbers, but it may cause problems for > other distributions if Sugarlabs start releasing new packages with _lower_ > version numbers than the older ones. > > As an example, are you sure that your Mozilla web interface supports > resetting version numbers? Do the install mechanisms in Sugar itself? Yes, that's why I'm suggesting doing it for 0.88, so we have time to patch whatever needs to be patched. About newer activity versions with dotted version numbers not updating older ones in <=0.86 because they are interpreted as older, I guess we have three options: - accept it as-is, activity authors that want older versions of Sugar to update to their bundles need to also produce bundles with undotted version numbers (messy), - patch older versions to recognize the new scheme (won't be possible for many/most deployments), - start the dotted series from the last integer used: Browse-112.1, Browse-112.2, etc (ugly). Any better options? Regards, Tomeu > > - 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) > > iQIcBAEBCgAGBQJKxfHbAAoJECx8MUbBoAEhFwQQAKtVsYHUt2LllEVcllmE2wYU > 5hJv56FuLBMBf0cWd9TXsF5649i8KIgo/DYSQps1rRJx7prjYErX3EyjHwOcw72U > h0fmWVjjQUz4cw7KvR7Prd0Xu6ndVHkcsEkA0x7bsn0rW6c+NHRantVVPdLX4dY1 > k4xC+77CjCgPKOiWV1FtKFc06ioOYorLcx1mW1L9Bi7T+j9IQqO5QY571RuA9PgV > FXHtXK308PYzLfYc/YHf4kWaSoaigWfIp7VCoVyBvhPcoTEKuJQR0CWIA2HneZeO > gP84WAZD/51eWpKi/0zZ4s3rpixjOKiMQdc7yea5UI00DI38NxvhJgEv7dmKnTHU > 85/Lwgb5x6R1BMWZYMq5E770BXXmSE7uNHfTLnlYXSRoExUxFhMBjYIt8/KHCRww > ZCjwx7BbqPjk0Uarh2H0HMufe2PrL5/WZ4id7ustyFm2g+FW6nMBTXyaTAZyG9M4 > +kYpvlEHwH8guDi2bWmIUfOHo042OYWxNOgvv3IKG4LPuge3MSGPsjovtqzRMggi > kQTxnRCXDpbvwY/Q3uvW7Mco2uPv/c4YXt7QwbYcnrfww6dEobPMrdSGn+o+X342 > Ji3LZ0TnbPw2tP/hGqmEy2uO2OKD3o07n9abu4AKinIR/dgnJ3jkqo8SB+DxwXLu > l9rmYDuYNC+HR6ChLUoc > =XkYV > -END PGP SIGNATURE- > > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > > -- «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] Namespace for 0.84 updates to Browse and Chat?
Hi Tomeu (and others), On Wed, Sep 30, 2009 at 06:48:05PM +0100, Tomeu Vizoso wrote: sorry for the late reply, this is a very good question. I think we should move to dotted version numbers for activities in 0.88, maybe interpreting a version number without a dot as 0.xx. For now and for your specific use case, what about preppending 0.84/0.86 to the activity version number? Debian supports resetting version numbers, but it may cause problems for other distributions if Sugarlabs start releasing new packages with _lower_ version numbers than the older ones. As an example, are you sure that your Mozilla web interface supports resetting version numbers? Do the install mechanisms in Sugar itself? - 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] Namespace for 0.84 updates to Browse and Chat?
Hi, sorry for the late reply, this is a very good question. I think we should move to dotted version numbers for activities in 0.88, maybe interpreting a version number without a dot as 0.xx. For now and for your specific use case, what about preppending 0.84/0.86 to the activity version number? Regards, Tomeu On Tue, Sep 22, 2009 at 10:10, Jonas Smedegaard wrote: > Hi, > > As I understand it, Sugarlabs wants to keep things simple for users by only > using the equivalent of "major numbers" when versioning Activities. > > I am wondering, however, what version numbers can be expected for potential > future bugfix releases of Browse and Chat targeted 0.84, as it seems to me > that there have been left no natural numbers between latest 0.84-compatible > releases and first 0.85-requiring releases. > > I ask because I would prefer to setup package tracking in Debian, and these > two packages seems impossible to have a newer release by your chosen > numbering scheme. > > > Kind regards, > > - 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) > > iQIcBAEBCgAGBQJKuJSXAAoJECx8MUbBoAEhVWsP/RMpzkitqQMg2um/L2AUdAS8 > SiD1QMgMPoO9p43RsjRcgDMPVWN/P6zw2nJYFa9/GoD3thfR8frbad+ZRNiKllyi > KgVV/MstsmOF9zR2drVRlwQXk0RDb/Uo1/Tug11cuLQCl5csvBQT2so9YZQ4zula > 4Pbk4X6Oi8zNOVzdHZXzhcr2ilfEaFhsGL18ILBN732DVo43ZkCExFZFRy6dwprD > q/o3iphNpBk5cnpxAJe6eaph7lY41sXLK12PCgMs1xjXHR+7n/3DfmLWsVT1vjIv > 6PA+dU2V1LWMwYYgMo+/rpC89x1I306nV5lk2s1IdbaTPHgfVm+CREEWFBdWgM9H > 0zXIuE0fngW6qBXoNzTegbwAQYtECqSSY66GdWxgZ/pJ+HIpPU+irreA1CmB6Ypz > nBmc1Ed1L2sHZrXOwUEZQFOCp0TUezNMOprDww1dUTxj1cQUPCqY8/E08/t29w85 > KZeAPMrjvSkkeAUZ46xsJbjy2P+jenVaf0TjSDbZQtLJEvq4vLQ7YHUbkoHv/fnI > HdkJotErMVt+Nv1Pc/kIWFZjZm9GFUqYKhfiyKQsc0cyDFLYTXSxltZDCoyX+gu4 > S8+sLTSstMqz3rS/6YWb3Wa3Xmk9AFAmoKV9oDY5U3yoQY98wXPmtKn7CCceIksw > k5wKwL326UKA+GKEi+IV > =AQmA > -END PGP SIGNATURE- > > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > > -- «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
[Sugar-devel] Namespace for 0.84 updates to Browse and Chat?
Hi, As I understand it, Sugarlabs wants to keep things simple for users by only using the equivalent of "major numbers" when versioning Activities. I am wondering, however, what version numbers can be expected for potential future bugfix releases of Browse and Chat targeted 0.84, as it seems to me that there have been left no natural numbers between latest 0.84-compatible releases and first 0.85-requiring releases. I ask because I would prefer to setup package tracking in Debian, and these two packages seems impossible to have a newer release by your chosen numbering scheme. Kind regards, - 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
