[Sugar-devel] Proposal of dotted activity version number

[Simon Schampijer]

Hi Gary,

thanks for your feedback.

On 10/05/2010 04:31 AM, Gary Martin wrote:
> 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.

Fair enough. Personally I think the new scheme is used in the following 
cases:
* platform dependent activities like Browse or Read
* I want to do several small releases (for example for people for 
testing, 1.2, 1.3, 1.4) before I get to a new major release (2).

>> 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 :(

Of course we don't break backwards compatibility. Integer versions will 
work as they did before.

>> 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.

If you fork you are on your own. Period.

And I would encourage everyone to always upstream changes. But in some 
cases it is good and desired to fork for a moment (trying something out, 
or the change is just not interesting to upstream at all). Those cases 
would be supported by the new scheme.

Regards,
    Simon