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 [email protected]
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?

[jorisvandenbossche]

I am planning on doing the rc release on Wednesday.
So that will probably mean #13755 (the Period Block) will not make it for the rc.

OK for everybody? (If there are other pressing issues for an rc, time to speak up :-))

[jorisvandenbossche]

Release candidate is out! Just sent the announcement, and there are both conda packages and wheels to test

[wesm]

thanks @jorisvandenbossche!

[jorisvandenbossche]

and @jreback !

[jorisvandenbossche]

@jreback pushed the remaining issues for 0.19.0 to 0.19.1 or later, so the queue is clear.

Are there any objections to releasing the current state as final 0.19.0?
I don't think there were any major reports warranting a second release candidate.

I would like to start testing the approach with a 0.19.x branch for a 0.19.1 release, so we can start with deprecations/breaking changes for 0.20/1.0 in master.

[jreback]

@jorisvandenbossche sure, let's release!

and certainly could test the backports if you'd like.

So IIUC.

you then want to also create a 0.19.x branch. master is then effectively 0.20.0 at this point. and will selectively backport?

[jreback]

prob need a script to make sure we don't miss any bug fixes. E.g. as soon as something is merged to master it needs to be considered for 0.19.x.

Further need to make sure travis/appveyor is testing that branch as well.

[jorisvandenbossche]

I will do the release tomorrow

[jorisvandenbossche]

Website and docs are updated, source and windows/mac/linux wheels are on PyPI and conda-forge packages are built as well!
Will do the announcement shortly