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

Jeff Reback jeffreback at gmail.com
Tue Sep 13 17:37:43 EDT 2016


typo on the deprecation issue, really should be:
https://github.com/pydata/pandas/issues/6581

IOW deprecations that need to be removed.

On Tue, Sep 13, 2016 at 5:29 PM, Jeff Reback <jeffreback at gmail.com> wrote:

> Oh and this means that we would do very very limited bug fixes on
> deprecated things (e.g. Panel / .ix); which for the most part are stale
> (IOW, not being worked on). I am going to create a milestone for things
> like this.
>
> Further, the issue of *when* to remove Panel/.ix entirely is an open
> question, is this 1.x, or 2.0?
>
> On Tue, Sep 13, 2016 at 5:26 PM, Jeff Reback <jeffreback at gmail.com> wrote:
>
>> 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/c58b17ec/attachment-0001.html>


More information about the Pandas-dev mailing list