[Sugar-devel] Activity Versioning - Dotted Scheme

[Bert Freudenberg]

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 <alsroot at 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 -