Tagging 0.13 #5796

ghost · 2013-12-30T17:06:28Z

@jreback , good to go?

jreback · 2013-12-30T17:08:24Z

yep
pls confirm build clean on windows/sparc (not sure when that builds)

jreback · 2013-12-30T17:13:22Z

I think you are prob better writing the announcement, if that's ok?

I had updated the whatsnew top section, so can use some of that.

thxs

ghost · 2013-12-30T19:55:34Z

All green, tagged and pushed.

Let's hold off on merges that would not fit into a 0.13.1 for a couple of weeks
after the ANN goes out, in case a showstopper is reported. Otherwise, we're in 0.14 now.

ghost · 2013-12-30T19:56:18Z

I'll send out an ANN after the binaries are up.

jreback · 2013-12-30T19:57:35Z

@y-p awesome!

can you setup the new version? e.g. so it shows say 0.14-dev?

I am not sure how to do that....

also I should add the 0.14 whatsnew?

jreback · 2013-12-30T20:02:52Z

@y-p added whatsnew template (but didn't link it in yet so docs will build for 0.13 correctly), and wont' show up on dev till its switched over (so won't be confusing like last time)

ghost · 2013-12-30T20:15:54Z

Good thinking about the docs.

Re versions, that's what it's like now: comment. The version string is constructed using number
commits since latest git tag, which makes dev versions lex ordered. Up until 0.13.0rc1, you saw 0.12.0-700-foo etc'

Is it bad enough to warrent another change in versioning scheme?

jreback · 2013-12-30T20:34:37Z

hmm; right now mine shows this....shouldn't this be 0.14-dev-...?

In [1]: pd.__version__
Out[1]: '0.13.0rc1-149-g5b69a0c'

ghost · 2013-12-30T20:53:02Z

user1@localhost ~/src/pandas (git)-[master] % git describe
v0.13.0-1-gaf9c025

read: "The first commit following the v0.13.0 release"

Did you git pull --tags ?

jreback · 2013-12-30T20:58:46Z

yep...not updating ...I see it in git tag...

jreback · 2013-12-30T21:03:04Z

does this get updated automatically?

[goat-jreback-~/pandas] more pandas/version.py
version = '0.13.0rc1-149-g5b69a0c'
short_version = '0.13.0'

ghost · 2013-12-30T21:03:07Z

pandas/version.py is updated only when running setup.py. Did you do setup.py develop?

But there is a bug there:

user1@localhost ~/src/pandas (git)-[master] % cat pandas/version.py         
version = '0.13.0-1-gaf9c025'
short_version = '0.14.0'

I'll open an issue and deal with it soon.
#5799

jreback · 2013-12-30T21:04:30Z

gr8...I don't do develop

ghost · 2013-12-30T21:07:30Z

setup.py install works too, don't see how we can avoid that step.
https://github.com/pydata/pandas/blob/master/setup.py#L233

the bug is version vs. short_version not having the same base version.

jreback · 2013-12-30T21:09:21Z

no what I mean is that shouldn't their be another commit that changes the base of these to 0.14-dev, (now)
?

like you did for the release

ghost · 2013-12-30T21:14:01Z

Unless we change the versioning scheme, then all dev versions until 0.14.0rc1 will be named 0.13.0-postX,
that's how it was in 0.13.0 as well, those dev versions were named 0.12.0-postX.

The version was changed: https://github.com/pydata/pandas/blob/master/setup.py#L192
It's just that it doesn't determine the dev versioning, only the latest tag does.

jreback · 2013-12-30T21:15:37Z

I think that's the problem...the short version should be 0.14-dev (is that #5799)

e.g. I also want to see the current version in master so need a 0.14-dev commit then?

ghost · 2013-12-30T21:43:45Z

after running install/develop, is this not what you see?

user1@localhost ~/src/pandas (git)-[master] % cat pandas/version.py       
version = '0.13.0-4-g7c6e5f6'                     
short_version = '0.14.0'

I agree It's not intuitive, but we're in the 0.14.0 cycle and 4 commits after the 0.13.0 release.
How do you think it should work? we can't know what the next tag will be, 0.13.1, 0.14.0rc1
0.14.0rc2, etc'.

short_version never had a dev qualifier added to it afaik.

jreback · 2013-12-30T22:15:14Z

no that's what I see..I see your point...ok then

ghost · 2013-12-30T22:20:01Z

I know it's not pretty, better idea welcome.

jtratner · 2013-12-30T22:28:42Z

Okay - why can't we just tag it as 0.14-dev now? It might not be pretty from reading the branch, but it would certainly be more convenient for us. Last time it caused some confusion to have everything named 0.12...

jreback · 2013-12-30T22:30:13Z

or could tag as 0.13.1-dev (and then later change to 0.14) if needed

ghost · 2013-12-30T22:40:19Z

Because tags are releases and changing conventions introduces inconsistency and usually
breaks something you didn't anticipate, and there's no way to erase the mistake since
history/tags should be immutable.

We can change anything, if there's a good enough reason. What's the actual inconvenience involved?

jtratner · 2013-12-30T23:00:30Z

It's very helpful to differentiate between released versions and development versions when people post bug reports. I'd rather have pandas.__version__ be 0.14-dev-89-afawef because someone posting that will say "Hey, this is 0.14!". frankly, might be easier to just hardcode the version and then swap out whatever git says, so like this:

$ # What I *want* to have happen
$ git describe
v0.13.0-5-g2a9245e
$ python -c "import pandas; print pandas.__version__"
v0.14.0-dev-5-g2a9245e

If it says 0.13 in it, they'll say it's 0.13 and we'll have to check against current master which costs an extra back and forth. Plus, it's confusing whenever anyone posts pandas output with version number.

ghost · 2013-12-30T23:28:23Z

Dev versioning is broken. #4046 was merged 5 months ago and I haven't seen a case where this kind of
confusion arose. Were there?
You're describing a case where a user will now report a problem in master
as being in 0.13. neither short_string=v0.14.0 nor full_version=v0.13.0-5-g2a9245e
can cause that confusion. print_versions output is always unambiguous as well.

But, I agree(d) this is ugly. We should be able to do what you described without
resorting to phantom-release tags. let's wait a few days to see if a corner case
springs to mind before going over though.

jtratner · 2013-12-30T23:55:31Z

I'll go look around for examples of confusion, but it may just be me in my
own head :P

ghost · 2013-12-31T00:10:18Z

nah, your points are valid. I'm just unconvinced that the current state of affairs isn't the
safest bet all things considered. Maybe a new year will help.

ghost · 2013-12-31T00:41:09Z

#5803 to align with how versions worked up until now. Mistake on my part when tagging the release.

ghost · 2014-01-03T01:37:59Z

I put together a wiki page on our release process https://github.com/pydata/pandas/wiki/Release-Checklist

feedback/additions welcome.

ghost · 2014-01-03T20:12:41Z

@jreback , @jtratner

#5812
https://groups.google.com/forum/#!topic/pydata/wSze3Z6P4Gs

We have to tag a 0.13.1 within a couple of weeks. Like I feared, you can never know in advance
what the next version will be.

cc @dartdog

jreback · 2014-01-03T20:17:07Z

yep...prob useful to do

jreback · 2014-01-03T20:17:59Z

shall create a 0.14 milestone...then move appropriate issues to 0.13.1?

ghost · 2014-01-03T20:21:16Z

I already created a 0.14, but it makes more sense to rename 0.13.1 to 0.14 and take all the
issues with it, then move just the few already merged back to 0.13.1.

jreback · 2014-01-03T20:22:55Z

ok....of course I renamed 0.14 to 0.13.1....i'll create and move everything to 0.14....we can then move selected ones to 0.13...

bug fixes for now I think

jreback · 2014-01-03T20:24:54Z

@y-p I think we are trying to do at the same time....you finish

ghost · 2014-01-03T20:25:29Z

No, I'm hands off, you have the con.

ghost · 2014-01-03T20:33:23Z

Whoa nelly, I just saw some open issues closing. careful.

jreback · 2014-01-03T20:36:15Z

@y-p I don't think anything closed...?

jreback · 2014-01-03T20:38:27Z

@y-p @jtratner @jorisvandenbossche feel free to move things to 0.13.1 as needed/appropriate

I just put a smattering

ghost · 2014-01-03T20:42:15Z

went through the git log since v0.13.0 and added just one missing PR.
looks good.

jreback · 2014-01-03T20:43:18Z

ok gr8

jreback · 2014-01-03T20:50:23Z

@y-p u r right...some how a bunch of issues got closed....reopening...

ghost · 2014-01-03T20:56:35Z

@jreback , if you didn't manually close them by mistake and they closed when you renamed
a milestone, it's a bug in GH and we should send support a heads up. It could do some real
damage to someone in the future.

Did you?

jreback · 2014-01-03T21:21:01Z

ok...here's the sequence

renamed original 0.14 milestone to 0.13.1 (me)
created 0.14 milestone (you)
selected issues page-by-page and changed milestone to 0.14 (17 pages)
moved select issues back to 0.13.1

I think a smattering of issues got closed in 3 (maybe 10-15), example is this: #4867

ghost closed this as completed Dec 30, 2013

ghost mentioned this issue Dec 30, 2013

version.py version and short_version are inconsistent #5799

Closed

This issue was closed.

Tagging 0.13 #5796

Tagging 0.13 #5796

Comments

ghost commented Dec 30, 2013

jreback commented Dec 30, 2013

jreback commented Dec 30, 2013

ghost commented Dec 30, 2013

ghost commented Dec 30, 2013

jreback commented Dec 30, 2013

jreback commented Dec 30, 2013

ghost commented Dec 30, 2013

jreback commented Dec 30, 2013

ghost commented Dec 30, 2013

jreback commented Dec 30, 2013

jreback commented Dec 30, 2013

ghost commented Dec 30, 2013

jreback commented Dec 30, 2013

ghost commented Dec 30, 2013

jreback commented Dec 30, 2013

ghost commented Dec 30, 2013

jreback commented Dec 30, 2013

ghost commented Dec 30, 2013

jreback commented Dec 30, 2013

ghost commented Dec 30, 2013

jtratner commented Dec 30, 2013

jreback commented Dec 30, 2013

ghost commented Dec 30, 2013

jtratner commented Dec 30, 2013

ghost commented Dec 30, 2013

jtratner commented Dec 30, 2013

ghost commented Dec 31, 2013

ghost commented Dec 31, 2013

ghost commented Jan 3, 2014

ghost commented Jan 3, 2014

jreback commented Jan 3, 2014

jreback commented Jan 3, 2014

ghost commented Jan 3, 2014

jreback commented Jan 3, 2014

jreback commented Jan 3, 2014

ghost commented Jan 3, 2014

ghost commented Jan 3, 2014

jreback commented Jan 3, 2014

jreback commented Jan 3, 2014

ghost commented Jan 3, 2014

jreback commented Jan 3, 2014

jreback commented Jan 3, 2014

ghost commented Jan 3, 2014

jreback commented Jan 3, 2014