Create maintenance branch for 0.13

[jtratner]

@jreback and I were discussing and we think it makes sense to freeze features for 0.13 and have master focus on 0.14-dev. Just wanted to throw it out there to make sure everyone is okay with this. After this point, we're only going to allow doc changes and, until 0.13 is released, we'll backport bug fixes as well.

I think it's better to keep master as bleeding edge so it's simpler for new contributors. If no one objects, wherever master is 24 hours-ish from this issue I'll mark current master as 0.14-dev and checkout a separate rc/0.13 branch.

[ghost]

I just saw this by mistake. Seems strange you didn't send this to pandas-dev,
or mention others. especially given a 24 hour ultimatum. Isn't that a little heavy-handed?
Don't assume devs see every new comment on github. You know the BFDL doesn't.

First, there's #5550 to get in before a feature freeze. Also, please be careful in choice of tags, you should maintain the total ordering on dev versions into the future.

I completely agree there's a problem with the release process, that's largely the cause why
the 12.1 and 11.1 bugfix releases never happened I think. The current model may slow things down
but it does have the benefit of keeping things simple and functioning by design.
Fixing the release problem would go a long way towards making this unneccesary.

How will this work? will rc and the final release live on the same branch?
if so the branch name is wrong. Where will 0.13.1 go? will there even be bugfix releases going
into the future? how do you maintain the backport queue and make sure things don't get missed?
who's responsible for backporting (the team? the PR submitter? an individual?)? what happens if no
one wants to?

I'm not against it, just want to know there's a plan and hear what it is.

[jtratner]

Okay I won't do this yet. I thought everybody got pinged by this. Jeff and
I had just mentioned it.

[jtratner]

(I just don't have time to respond right now about to get on a plane.)

[ghost]

You're not alone, wes suggested it too on -dev (for doing x.1 releases), we all agree there's a problem.
But perhaps it's really the release delays that should be fixed, rather then working around them.

[jtratner]

Okay, I'm going to send something to pandas-dev as well. My expectation is
that I (and probably @jreback as well) will be back porting bug fixes.

My goal here is actually to limit the number of new features we push into
0.13. There's a lot of push to add or improve features and I think it would
help to limit what we add in right before a release. Goal of having
separate branch for 0.13 is that we won't have to tell new contributors to
change anything.

@y-p - I don't see how we can maintain the tag ordering here. It's based on
commit number from last tag no?

[ghost]

Seems like the urgency to get something into a release is a symptom of the
release cycle being too long, and that's largely because releases are repeatedly delayed.
The commiters are doing a kickass job squashing the issue queue, but pandas stil
depends on wes for the final bit and he's busy**n. which is why he wants to offload it.

How will the backport queue be managed? keep a list and periodically backport? labels? require
a backport simultaneously with merge into master?

Not sure I get your point about new contributors, and nm re tags I misread your comment.

[jreback]

let's close this as its passe for now

[jtratner]

Agreed. How are we tracking where the release candidate officially is? Tip
of master?

[jreback]

yep