[Pandas-dev] Version Policy following 1.0

[Joris Van den Bossche]

Coming back to this thread (as I don't think we really reached a conclusion)

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

> I hope you don't mind the intrusion of a non-pandas dev here.
>

As you well know ;) we certainly don't mind the intrusion. It's exactly
from people depending on pandas that we want to hear about this.


> 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.
>
> For me, a possible reason to go for a SemVer-like versioning scheme is
*not* to do no more breaking changes / clean-up, but rather the opposite.
To make it easier to do big changes (if we agree on wanting to do them), as
we then have a mechanism to do that: bump the major version.
For example, I very much want that we, at some point, make the nullable
integer dtype and a potential new string dtype the default types for pandas
(which will inevitable a breaking change). I would like to see us move
forward to a more consistent handling of missing values across types (see
https://github.com/pandas-dev/pandas/issues/28095), optional indexes,
...Those will only be possible with at some point doing a bigger breaking
change release.

On Mon, 22 Jul 2019 at 17:54, Tom Augspurger <tom.augspurger88 at gmail.com>
wrote:

> ... 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.
>
> It's true that others in the ecosystem (numpy, scipy, scikit-learn) use a
rolling deprecation. But, a big difference is that they in principle only
do deprecations and no breaking changes.


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

 After 1.0, Arrow will follow strict backwards compatibility guarantees and
SemVer *for the format *(
https://github.com/apache/arrow/blob/master/docs/source/format/Versioning.rst).

For library versions (eg the C++ library, or pyarrow), the document states
to also use SemVer, but I don't think it already has been discussed much
how to deal with that in practice (for the format the rules are much
clearer).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pandas-dev/attachments/20190910/102f18c5/attachment.html>