[Pandas-dev] Version Policy following 1.0

[Tom Augspurger]

Thanks Matt,

Marc, do you have thoughts on that? As you say, SemVer is more popular in
absolute terms. But within our little community (NumPy, pandas,
scikit-learn), rolling deprecations seems to be the preferred approach.
I think there's some value in being consistent with those libraries.

Joris / Wes, do you know what Arrow's policy will be after its 1.0?

Tom

On Sun, Jul 21, 2019 at 10:10 AM Matthew Rocklin <mrocklin at gmail.com> wrote:

> Hi All,
>
> I hope you don't mind the intrusion of a non-pandas dev here.  In my
> opinion SemVer makes more sense for libraries with a well defined and
> narrowly scoped API, and less sense for an API as vast as the Pandas API.
>
> My ardent hope as a user is that you all will clean up and improve the
> Pandas API continuously.  While doing this work I fully expect small bits
> of the API to break on pretty much every release (I think that it would be
> hard to avoid this).  My guess is that if this community adopted SemVer
> then devs would be far more cautious about tidying things, which I think
> would be unfortunate.  As someone who is very sensitive to changes in the
> Pandas API I'm fully in support of the devs breaking things regularly if it
> means faster progress.
>
> Best,
> -matt
>
> On Sun, Jul 21, 2019 at 2:24 AM Marc Garcia <garcia.marc at gmail.com> wrote:
>
>> Personally, I think will make things easier for users if we use SemVer.
>> Mainly because as a user I think it's somehow intuitive that I can upgrade
>> for example from 1.1.0 to 1.8.0 without having to edit code. But I'd expect
>> to have to take a closer look and see incompatibilities when I migrate from
>> 1.* to 2.*.
>>
>> Personally I don't usually know the deprecation policies of packages, and
>> I don't expect most pandas users to know ours even now. So, the simplest
>> the better.
>>
>> Also, for ourselves, I think it's easier and more efficient to forget
>> about removing code in minors, and to do all the removals for majors.
>>
>> I agree this comes at the cost of bigger changes in major releases,
>> compared to a rolling policy. But IMHO it's worth.
>>
>>
>> On Fri, 19 Jul 2019, 21:58 Tom Augspurger, <tom.augspurger88 at gmail.com>
>> wrote:
>>
>>> On Wed, Jul 17, 2019 at 4:42 PM Brock Mendel <jbrockmendel at gmail.com>
>>> wrote:
>>>
>>>> Do we anticipate the rate of deprecations decreasing significantly?
>>>> i.e. if right now we deprecated everything on which there is a consensus in
>>>> GH, would we be done for a while?
>>>>
>>>> If not, then I think we're better off sticking with zero-dot-*, or else
>>>> we'll be bumping major versions really frequently.
>>>>
>>>
>>> I think this is why I prefer sticking with rolling. If every release
>>> bumps the major version number, then no release is a major release.
>>>
>>> So my preference would be
>>>
>>> 1. Formally adopt and document that we using a rolling deprecation cycle
>>> 2. State that deprecations will be around for `N` major releases (3?)
>>> 3. Require that every new deprecation includes the version it'll be
>>> enforced in. e.g.
>>>
>>> ```
>>> DataFrame.get_dtype_counts is deprecated, and will be removed in pandas
>>> 1.3.0.
>>> Use DataFrame.dtypes.value_counts() instead.
>>> ```
>>>
>>> Tom
>>>
>>> On Wed, Jul 17, 2019 at 1:49 PM Tom Augspurger <
>>>> tom.augspurger88 at gmail.com> wrote:
>>>>
>>>>> Split from
>>>>> https://mail.python.org/pipermail/pandas-dev/2019-July/001030.html
>>>>>
>>>>> Following 1.0, I think we stop outright breaking APIs. I think that
>>>>> stability will be welcome to users.
>>>>>
>>>>> We still have to decide how we deprecate APIs. The two options are
>>>>>
>>>>> 1. Rolling deprecations: Essentially what we do today: An API is
>>>>> deprecated in release 1.1.0 and can be removed in (say) 1.4.0.
>>>>> 2. SemVer: An API may be deprecated in 1.x.0. It can be removed in
>>>>> 2.0.0
>>>>>
>>>>> Do people have preferences between the two? The (dis?)advantage of
>>>>> Semver is that all the API-breaking changes are restricted to a single
>>>>> releases. With rolling deprecations, the upgrades from any 1.x to 1.y
>>>>> should be smoother than 1.x to 2.x.
>>>>>
>>>>> Once we choose a strategy, we may want to formalize release schedules
>>>>> around it.
>>>>>
>>>>> Tom
>>>>> _______________________________________________
>>>>> Pandas-dev mailing list
>>>>> Pandas-dev at python.org
>>>>> https://mail.python.org/mailman/listinfo/pandas-dev
>>>>>
>>>> _______________________________________________
>>> Pandas-dev mailing list
>>> Pandas-dev at python.org
>>> https://mail.python.org/mailman/listinfo/pandas-dev
>>>
>> _______________________________________________
>> Pandas-dev mailing list
>> Pandas-dev at python.org
>> https://mail.python.org/mailman/listinfo/pandas-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pandas-dev/attachments/20190722/ec784a55/attachment.html>