[Pandas-dev] Version Policy following 1.0

[Tom Augspurger]

Thanks Joris,

I think your point about versioning and release cadence is important. We
have two axes we can operate along: How often we release (breaking)
changes, and how what version number we assign to those releasees.

For example: SemVer allows a 1.3.0 release that deprecates a feature, and
then releasing 2.0.0 the next day that enforces the deprecation. We
obviously don't want to do that; we'll continue to give the community time
to adjust.

---

> Those [changing NA values] will only be possible with at some point doing
a bigger breaking change release.

In principle, we could have config options to opt into the new behavior.
But we've never done that before, and personally I would likely prefer a
breaking change, with a bump in the major version (assuming we're doing
SemVer).

Tom


On Tue, Sep 10, 2019 at 3:38 PM Joris Van den Bossche <
jorisvandenbossche at gmail.com> wrote:

> 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).
> _______________________________________________
> 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/20190911/1b97ac58/attachment.html>