[Sugar-devel] [ANNOUNCE] Sucrose 0.86 Branching - Activity versions

[Gary C Martin]

On 1 Oct 2009, at 15:23, Simon Schampijer wrote:

> On 10/01/2009 03:55 PM, Eben Eliason wrote:
>> On Thu, Oct 1, 2009 at 7:16 AM, Peter  
>> Robinson<pbrobinson at gmail.com>  wrote:
>>> On Thu, Oct 1, 2009 at 12:08 PM, Wade Brainerd<wadetb at gmail.com>   
>>> wrote:
>>>> On Thu, Oct 1, 2009 at 5:20 AM, Simon Schampijer<simon at schampijer.de 
>>>> >
>>>> wrote:
>>>>>
>>>>> *Activity versions*
>>>>> As we use integers for activity versions (this really has to  
>>>>> change for
>>>>> 0.88 with introducing minor versions), we need to cope for the  
>>>>> famous:
>>>>> stable/unstable version issue. I would say to leave at least 3  
>>>>> version
>>>>> numbers open when doing a new unstable release. An example:
>>>>>
>>>>> Walter has submitted TurtleArt 69 for 0.86. He reserves the  
>>>>> numbers 70,
>>>>> 71, 72 for bug fix releases. When he is doing a release from the
>>>>> unstable master branch (0.88 development) he is using numbers>   
>>>>> 72.
>>
>> This still seems pretty limiting. What if he finds he actually  
>> needs 4
>> bugfix releases? Why should replace a limited system with another
>> that's just as limiting (This suggestion is kind of like going from
>> O(0) to O(3), instead of O(n) like we really need).
>>
>
> Just to be clear, this is just a workaround for 0.86 - as we would  
> need
> some changes to support the dotted version numbers. For 0.88 we can do
> the dotted versions.


Perhaps I'm just having a 'bad hair' day ;-) But...

How do activity authors continue to support the large 0.82 (and the so  
far smaller 0.84, 0.86) deployments? As an activity author my primary  
focus is for existing deployments, making work backwards compatible.  
i.e. what will happen when a sugar 0.82 user downloads/shares a bundle  
named Labyrinth-12.0.1? I understand why this is not true for core  
sugar devs, or authors who have to rely on a specific component of a  
specific sugar build, but it almost seams like such Fructose  
activities are perhaps the only ones that need some complex version  
string matrix (like as used for the Glucose package versioning). The  
rest of us can just tick on with our integer releases that support all  
releases?

I guess Fructose is in need of some discussion ;-)

Regards,
--Gary