[Sugar-devel] Proposal of dotted activity version number

[Gary Martin]

On 5 Oct 2010, at 00:30, James Cameron <quozl at laptop.org> wrote:

> On 05/10/2010, at 10:16 AM, Tim McNamara wrote:
>> My strong preference is for Activities to rapidly increase their integer numbers, rather than creating a complex tree of point releases. My feeling is that a tree of three or more levels deep adds complexity to new Learners. It goes against the 'low floor, no ceiling' philosophy by requiring that Learners learn a new counting system, on top of integer increments.

Tentative +0.25 as well if others think this is really, really necessary - but I personally never want to have to maintain two or more versions of any activity (what the doted version support is really all about). When we hit a show stopping api break, consider the last working release the end of line, or upgrade to a newer Sugar that is supported by a newer activity release.   

> Yes.  Better than the current situation though.

Only if the change does not break 0.82 and 0.84 integer based updates/installs. Or are we saying that as of 0.92 every activity will have to fork and break with past versions of Sugar anyway? If so I can see little motivation as an activity developer to move to 0.92 for quite some time, who wants to write activities almost no deployment will use for likely 6 to 18 months at best? I guess if this is the case, moving to a new versioning scheme in 0.92 is fine even if it breaks 0.82 and 0.84, as no activities for 0.92 will run anyway on past Sugar versions :(      

> Ideally, instead of presenting a version number to a learner, a graph describing the history of the activity source and dependencies could be displayed.

Ouch.

> Alternatively, separate the Learner visible numbering from the software release numbering, and leave the visible numbering within the scope of a deployment.  Then one deployment's Browse-190 may be different to another deployment's Browse-190.

Oh please for the love of maintenance no, how will we ever deal with bug reports. If a deployment decides to fork, say Physics, and introduces their own bugs and/or breaks Journal entry compatibility by adding some feature, I do not want to burn up any more of my life dealing with tickets reported with ambiguous version information, it's bad enough dealing with tickets from folks not testing against the current release.   

Regards,
--Gary

> --
> James Cameron
> System Test Coordinator
> One Laptop per Child
> 
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel