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

[Tomeu Vizoso]

On Tue, Oct 13, 2009 at 18:23, Jonas Smedegaard <dr at jones.dk> wrote:
> 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!).

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