[Sugar-devel] Activity Versioning - Dotted Scheme

[Simon Schampijer]

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