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

[Daniel Narvaez]

Gah, s/what is deprecated and what is not/what is dropped and what is not/


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/5a254e8e/attachment.html>