[Sugar-devel] Namespace for 0.84 updates to Browse and Chat?

[Jonas Smedegaard]

On Tue, Oct 13, 2009 at 04:06:08PM +0100, Tomeu Vizoso wrote:
>On Fri, Oct 2, 2009 at 13:28, Jonas Smedegaard <dr at jones.dk> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
Url : http://lists.sugarlabs.org/archive/sugar-devel/attachments/20091013/04b4de60/attachment.pgp