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

[Wes McKinney]

On Tue, Sep 13, 2016 at 10:07 PM, Tom Augspurger
<tom.augspurger88 at gmail.com> wrote:
>
> On Tue, Sep 13, 2016 at 4:37 PM, Jeff Reback <jeffreback at gmail.com> wrote:
>>
>> 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.
>
>
> This all sounds good. The important point is we should only hold off on
> things, enhancements *or bugfixes*, because they get too deep into the
> internals,
> not just because they're an enhancement.
>

I think the watershed will be "does it rebase cleanly?". At least for
a while the pandas 2.0 branch (once we get going) won't be in conflict
but at some point rebasing will become more difficult. We'll have to
make best efforts to avoid the conflict for as long as possible. I
think this is OK, because the "new DataFrame internals" is a large and
fairly independent effort in the early stages, so the refactor to
change things out will happen somewhat late in the process after the
essential features and behavior have been implemented.

>>>>
>>>> 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.
>
>
> I think deprecating ix and Panel in 0.20, is OK, as long as we 1.) make it
> clear that they're being removed in 2.0, but around for all of 1.x LTS,
> and 2.) provide an option to silence them. I don't feel strongly about this
> though.
>
>>>>>
>>>>>
>>>>> - 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
>>>>
>>>>
>>>
>>
>>
>> _______________________________________________
>> Pandas-dev mailing list
>> Pandas-dev at python.org
>> https://mail.python.org/mailman/listinfo/pandas-dev
>>
>
>
> _______________________________________________
> Pandas-dev mailing list
> Pandas-dev at python.org
> https://mail.python.org/mailman/listinfo/pandas-dev
>