[Pandas-dev] Version Policy following 1.0

[Marc Garcia]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pandas-dev/attachments/20190721/0cf743fe/attachment.html>