[Sugar-devel] Deprecation policy - was: About show-launcher option

[Daniel Narvaez]

My thoughts about semantic versioning

* I think we should be flexible on the deprecated API we drop. Bumping
major doesn't necessarily mean we have to drop all deprecated API.
* I'd really like to adopt it but I'm not sure how to apply it to our six
months cycle. It seems to be thought for continuous development. (Can we
please please switch to continuous development? :P).
* I think we should adopt it for sugar-web.



On 14 January 2014 01:15, Daniel Narvaez <dwnarvaez at gmail.com> wrote:

> On top of Manuel proposal or in alternative?
>
> I mean, does bumping the major version imply that all the deprecated bits
> are dropped? Or do we just bump major whenever we make an API break but we
> decide case by case what is deprecated and what is not?
>
>
> On 14 January 2014 01:02, Code Raguet <iraguet at activitycentral.com> wrote:
>
>> what about something like this http://semver.org/?
>>
>>
>> On Mon, Jan 13, 2014 at 8:32 PM, Daniel Narvaez <dwnarvaez at gmail.com>wrote:
>>
>>> On 13 January 2014 18:21, Manuel Quiñones <manuq at laptop.org> wrote:
>>>
>>>> 2014/1/13 Daniel Narvaez <dwnarvaez at gmail.com>:
>>>> > IMO it should be deprecated and then removed at some point. In
>>>> general, I
>>>> > think our approach to API stability is way too ad hoc. We need some
>>>> rules,
>>>> > even if very simple, to define what is public, how/when it is
>>>> deprecated,
>>>> > and how/when it is removed.
>>>>
>>>> What about?
>>>>
>>>> - when an API change arises, we discuss a time range for activities to
>>>> adapt
>>>>   the time range is measured in number of releases
>>>>
>>>> - we do the change in the code, leaving the old code
>>>>
>>>> - the deprecation is marked in the old code, adding a comment, logging
>>>> a warning
>>>>
>>>> - the deprecation is announced in each release notes,
>>>>   asking activity developers to update their code
>>>>   mentioning for how many number of releases it will keep working
>>>>
>>>
>>> I think we should have a section in sugar-docs where we note the
>>> deprecations (and the time range). So we add them as we go.
>>>
>>>
>>>> - activity developers upload new versions to activities.sugarlabs.org,
>>>>   marking the corresponding Sugar version
>>>>
>>>> - after the aggreed time, the old code is removed
>>>>
>>>> This is more or less what we've been doing.  I think when the toolbars
>>>> API changed we gave about 1 year for adaptation.
>>>
>>>
>>> This sounds great to me.
>>>
>>> We just need a way to know what is public API and what is not. Maybe,
>>> for new code, everything is public unless it has the usual underscore or
>>> there are inline docs mentioning it's not public. For old code well... I
>>> guess we just decide case by case.
>>>
>>> Also I think API is frozen on the day of the stable release, it's fine
>>> to make changes until then, otherwise it becomes really difficult to
>>> develop new API.
>>>
>>> _______________________________________________
>>> Sugar-devel mailing list
>>> Sugar-devel at lists.sugarlabs.org
>>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>>
>>>
>>
>
>
> --
> Daniel Narvaez
>



-- 
Daniel Narvaez
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20140114/15b22779/attachment-0001.html>