RLS: 0.19.0

[jorisvandenbossche]

Issue to track the progress towards the 0.19.0 release.

cc @jreback @shoyer @sinhrks @TomAugspurger @wesm

[jorisvandenbossche]

I think it would be nice to try to target a release candidate by the end of this month / last week of August (although that is approaching fast). That would mean stopping with merging larger features in master for now.

There are currently still 166 open issues tagged with 0.19.0 (https://github.com/pydata/pandas/issues?q=is%3Aopen+is%3Aissue+milestone%3A0.19.0). I will go through them and push some of the issues to 0.20 / 'Next major release' milestones (starting with the minor enhancement requests and non-critical bugs).

If there are any issues you would really like to see in 0.19.0, maybe comment on those issues (or here).

Sounds OK / remarks ?

[jorisvandenbossche]

@sinhrks Your work on Periods adding a period type is maybe one of the discussion points .. (#13755, #13941 et al). Personally, it feels a bit too close to the deadline to me if we want to meet the end of august deadline. But of course, we could also postpone the release a bit.

[jreback]

I think we should include the period change
will merge all of this next week

[TomAugspurger]

End of August sounds good. I'll be a bit busy prepping talks for PyData Chicago that weekend and getting this side project off the ground, but I'll help review as much as I can.

[sinhrks]

personally it is nice to include #13941 at least, as it allows broaden index cleanup based on dtype (not index specific logic like freq comparison, etc).

[jreback]

#13767, #13854, #13755, #13660 should be merged before we do a RC1. we can push #13755 if needed (but then would want an RC2).

I would push all other issues w/o an open PR that is actually marked for 0.19.0. Any other PR's already marked for 0.19.0 should be pushed to update. Anything else don't mark for 0.19.0, unless its about to be merged (then of course mark and merge)

cc @jorisvandenbossche @sinhrks

[sinhrks]

#13755 seems to be little hard (there are some issues related to coercion / ops should be fixed prior to it). Do you have re-scheduled date considering remaining?

[jreback]

the remaining are ready to go I think just need s bit of review - ideally like to like to do asap

[jorisvandenbossche]

Yes, that seem the blocking PRs for a release candidate(maybe also #14127). Personally, if we want #13755 in 0.19.0, I think we should have it the release candidate.

I further trimmed down the number of issues tagged with 0.19.0 to 30 (of which half or so will be closed by an open PR for 0.19.0).
As I would like to keep some of those issues tagged without them being a blocker (just to find them easier), I quickly created a 0.19.0rc milestone to track the blockers (after th rc we can just rename them back to 0.19 and remove the milestone).

[wesm]

Maybe this is a radical idea and too late for 0.19, but thoughts on deprecating .ix either now or in 0.20 / 1.0?

[shoyer]

Yes, we should do this (probably too late for 0.19, though).

On Thu, Sep 1, 2016 at 6:10 AM, Wes McKinney notifications@github.com
wrote:

Maybe this is a radical idea and too late for 0.19, but thoughts on
deprecating .ix either now or in 0.20 / 1.0?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#13991 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABKS1kJqCotwlJxQz7qOyIb4CsaTz0qGks5qls6wgaJpZM4JjrpT
.

[jreback]

We need another major release, 0.20.0, to complete deprecations I think. Even though 0.19.0 has a lot, we need to push thru almost everything remaining big ones in another release. Further we should do this and NOT call it 1.0.

[wesm]

That seems OK as long as we are throttling back on new features / API changes. Let's start making a master list of desired deprecations in 0.20 and 1.0?