[Pandas-dev] Future Deprecation Policy

Joris Van den Bossche jorisvandenbossche at gmail.com
Wed Sep 26 16:29:09 EDT 2018


What I remember is that we somewhat opted for option 1 (SemVer), but it is
true that for example numpy (and I think many of the other packages in the
pydata ecosystem) uses a more rolling deprecation cycle, and we didn't
really take this into account in the discussion.

The reason I say to remember option 1 is because I think we talked about
the promise of *"code that works in 1.0 should keep working (possibly with
deprecation warnings) in the 1.x cycle"*
(of course always with some exceptions where deprecations are impossible /
people where relying on buggy beahviour)

One example to look at is Django's policy:
https://docs.djangoproject.com/en/dev/internals/release-process/#internal-release-deprecation-policy,
which they describe themselves as a "loose form of semver".
This also corresponds more or less to the promise I quoted above I think.

Anyway, it is good to further discuss this and maybe take a more formal
decision about it.

(and also, whatever we decide, I think it would be good to have a page
describing our policy as django does)

Joris


2018-09-26 16:43 GMT+02:00 Tom Augspurger <tom.augspurger88 at gmail.com>:

> Hi all,
>
> At the sprint, we touched on this, but I don't recall there being a whole
> lot of
> discussion. I wanted to confirm that we're on the same page.
>
> Briefly, I see two options:
>
> 1. SemVer
>    Deprecations are introduced as needed. Enforcing a deprecation is a
>    backwards-incompatible change, and so is restricted to major releases
> only.
>
> 2. Rolling deprecations
>    Deprecations are introduced as needed. Deprecations are enforced N
> releases
>    after they were introduce (N typically being 2-3 "major" release in
> practice).
>
> Do people have a preference between these two schemes? Does the fact that
> NumPy
> uses a rolling deprecation policy swing us one way or the other?
>
> I've added this to the agenda for the meeting tomorrow, but wanted to give
> people a chance to collect their thoughts first.
>
> Tom
>
> _______________________________________________
> 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/20180926/ddaaf89c/attachment-0001.html>


More information about the Pandas-dev mailing list