👍 in general. I've used it for a couple of my projects and love the fact that I don't change the source to reflect the version--just eliminates duplication of information.

Note - the downside of this is that we do not have a good naming scheme for maintenance branches (e.g. you can't tell the difference between a build from the v1.4.x branch and the master branch). I proposed such a change in python-versioneer/python-versioneer#90, but haven't had it merged at this point.

The release guide page should also be updated: http://matplotlib.org/devel/release_guide.html

❤️

I am partial to the .postN style formatting so '1.4.3+2821.g2aae565' vs '1.4.3.post2821+g2aae565'

@WeatherGod That is out of date anyway see #3707

Also, just found that downloading zip files from my fork results in a useless version. See python-versioneer/python-versioneer#99. I'm not convinced that is a show-stopper though.
Overall, I'm happy with the the pro of not having to do version ping-pong commits vs the con's of:

• not having an explicit version string to look at
• cloned repos do not compute meaningful version strings from zip files

I am partial to the .postN style formatting so

Me too. I'll update the defaults.

👍 I guess this is a good reason to get #3707 in as well.

definitely agree that downloading zips from side-forks not having good versions is not a show-stopper (although, I am a bit confused as it looks like your fork has tags https://github.com/pelson/matplotlib/tags )

I'll convert that checklist over to rst as I go through it for this release.

although, I am a bit confused as it looks like your fork has tags

I just pushed them. Trying to figure out if the problem exists between the keyboard and the chair... 😉

hurray for race conditions!

Trying to figure out if the problem exists between the keyboard and the chair... 😉

Hmmm. Maybe it got a bit late - I just pushed the branch to upstream and downloaded from there (https://github.com/matplotlib/matplotlib/tree/versioneer), to the same result. I wonder if there is a git-ism that I've misunderstood...

Note to self: delete the branch tomorrow. (unless somebody beats me to it)

I'm going to have to call it a day today - should be available in T+14 hours @tacaswell.

Is this installation of versioneer up to date? If I understand correctly, there should be a section in setup.cfg that I can't find here. That could be related to this issue.

@pelson's versioneer-fu is well above my own, though. Forgive me if I misunderstood your way of doing this.

Both of my other projects use versioneer without setup.cfg stuff. It's all in setup.py.

The cfg component is in new versions only (and perhaps not essential,
depending on what you put in setup.py, but it seemed worth mentioning).

On Mon, Sep 14, 2015 at 6:07 PM Ryan May [email protected] wrote:

Both of my other projects use versioneer without setup.cfg stuff. It's
all in setup.py.

—
Reply to this email directly or view it on GitHub
#5064 (comment)
.

This happens on one of our day-job projects when downloading master as well, but it works when downloading tagged zips.

added a commit fc7683b to change version string format and merged locally

Is this installation of versioneer up to date? If I understand correctly, there should be a section in setup.cfg that I can't find here. That could be related to this issue.

Yes, it's up to date, but I patched the versioneer.py file to prevent the need for a setup.cfg, which I wanted to avoid if possible as I'd like people to be able to use their existing setup.cfg files for the next release of matplotlib. Not hugely pretty, but pragmatic.

@pelson's versioneer-fu is well above my own

I'm not so sure. I've gone deep to add some core functionality, but I confess I still don't use it daily for my own projects yet. Hopefully having it in mpl will help that though.