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<qu...@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
_______________________________________________
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
