[Pandas-dev] 0.20 and 1.0 timeline, 2.x interactions?

[Jeff Reback]

So here's what I am thinking.

We need a bug fix release (0.19.1) say 1 month. Then we need a 0.20.0 in
approx 3 months ('regular' major release). The difference here is we can
limit new additions to this release (prob just period dtype?) and do major
deprecation removal https://github.com/pydata/pandas/issues/13777 / add
anything else (e.g. Panel/.ix) deprecations.

Then we turn around and do a 1.0 say 1 month after that, which is the api
stable release.

So then the 1.x / LTS can continue with the following categories:

- bug fixes
- perf improvements
- deprecation removals (hate to do it, but we have to)
- minor / limited deprecations
- limited new enhancements

So mostly continue the usual pattern. Maybe with a higher hurdle for
introducing changes that are potentially disruptive. E.g. would we accept
Interval/IntervalIndex for example. This should have a new dtype. (that's
why I am picking on it).

I am promoting a pattern like this to avoid the pitfall of: 'hey pandas is
in LTS / stable, so we won't contribute any more, its just bug fixes' issue.

Jeff

On Tue, Sep 13, 2016 at 9:51 AM, Wes McKinney <wesmckinn at gmail.com> wrote:

> hi folks,
>
> Bumping this thread. At minimum we should start discussing what we may
> want to deprecate (e.g. Panels, .ix) in the next major release.
>
> - Wes
>
> On Wed, Sep 7, 2016 at 2:57 PM, Wes McKinney <wesmckinn at gmail.com> wrote:
> > Since we are close on the 0.19.0 release (thanks Joris for the hard
> > work!), I wanted to see if we can start assembling a concrete plan for
> > 0.20 and/or 1.0 (API-stability / maintenance branch begin). Depending
> > on the scope of the deprecations or other work desired for these
> > releases, it would be great ideally to reach 1.0 by Jan 1 or the first
> > couple months of 2017.
> >
> > On the pandas 2.0 side, I don't think that the timeline for 0.20 or
> > 1.0 will block progress from beginning. I'd soon like to start
> > prototyping some of the new designs we've been discussing to get some
> > concrete feedback on real working code (will create issues on
> > pydata/pandas-design to track). Once we establish some of the
> > essential design patterns (i.e. what does an alternative to the
> > BlockManager look like? How do we handle dynamic / multiple dispatch
> > based on type?) and feel comfortable with them, more of the "porting"
> > work can begin.
> >
> > I think as long as the pandas-2.x branch rebases cleanly for the first
> > while then there will be no conflict. At some point rebasing may not
> > be possible and we will need to come up with a backporting policy.
> >
> > Thanks
> > Wes
> _______________________________________________
> 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/20160913/76084360/attachment.html>