Coverage decreased (-0.04%) to 72.86% when pulling5ff196c on cwrowley:conda-build into86ebb1c on python-control:master.

Ifcontrol/_version.py is missing (or otherwise if anIOError exception is raised while trying to read from it), then the version string is "dev", which does not conformwith PEP 440.

My comment above applies also if__version__ fails to be found when executingcontrol/_version.py. Cf.line 7 of setup.py.

That's correct. And in that case, setup.py gives a UserWarning that 'dev' is an invalid version. This seems like a reasonable fallback to me, but do you have another suggestion?

Another concern: counting commits since a tag will fail in the case of branching. E.g., a version string of "0.6.6.post6" could occur for two distinct commits that have a common ancestor. While you make the commit hash available viacontrol.__commit__, why not include it in the version string?

My basic argument against not including some--possibly incomplete--version number in the source tree is that Git becomes a required dependency ofpython-control. E.g., a snapshot of the repo created viagit archive will not have any version specifier (except possibly the name of the directory, depending on howgit archive is called), and it will not be possible to install from that snapshot. This especially matters because GitHub provides a Web service likegit archive, e.g.,https://github.com/python-control/python-control/releases

While we sort out the version discussion, is it worth separating out the two aspects of this request and re-issuing a separate pull request for all but the versioning part? Just a thought.

@slivingston, the main reason I did things the way I did them is that I just copied what was done in binstar! I agree about the ambiguity of branches, but there shouldn't actually be any branching in the main releases, so that does not bother me.
About the dependency on git, I don't think it's quite accurate to say that Git becomes a required dependency of python-control. You need git if you want torelease a version (e.g., upload to PyPI or conda). But if you are justinstalling with pip or conda, you don't need git, because the version is baked into these distributions. So the dependency only affects those who are doing the releasing, or are doing something very nonstandard like installing from a git archive. Also, note that the current setup.py (which was copied from numpy) does try to callgit rev-parse HEAD, so if anything this change makes us less dependent on Git.
So I agree, it's not perfect, but I think the convenience and fool-proofness of just needing to specify the version once outweigh these drawbacks, which seem to only affect obscure situations. We do have an actual situation that has come up (namely, that the version currently on pypi does not match any version in the repository), and this solution would fix that and make sure things like that do not happen again.

@murrayrm, I suppose it would be possible to separate this into two pull requests, but I would have to change the conda configuration, and I'd rather not go to extra work to replace that with something that, in my opinion, does not work as well.

As I recall, the original mistake concerning the version on PyPI occurred because someoneuploaded a release without discussing it, froma fork of the main repo. Indeed, examine the version number insetup.py of that fork and compare withthe one on PyPI. Such could happen again, whether or not the version number is explicitly in the source tree.

Whilesetup.py from NumPy will try to callgit, it will append to the version number ".dev0+Unknown" if that fails. I am not sure that it is appropriately described as being more or less dependent on Git than the changset of this PR.

Nonetheless, I think my concerns about dependence on Git and duplicate version strings for distinct (non-release) commits can be addressed empirically. That is, perhaps we should just merge this PR, and try it for awhile.

By the way, besidesconda andpip, another major venue for getting python-control releases ishttps://sourceforge.net/projects/python-control/files/.

While setup.py from NumPy will try to call git, it will append to the version number ".dev0+Unknown" if that fails. I am not sure that it is appropriately described as being more or less dependent on Git than the changset of this PR.

All I meant was that in the new version,setup.py does not call git at all. The only time we call git is when distributing (runningmake_version.py).

Note that the numpy stuff has been unreliable for us (e.g.,#37), and the fix using the__NUMPY_SETUP__ global variable is even called "ugly" and "hackish" in the numpy source. The binstar approach just seems simpler and cleaner to me, since it clearly separates the "pre-build" (make_version.py) from the actual build (setup.py), instead of trying to do both of these things insetup.py.

That is, perhaps we should just merge this PR, and try it for awhile.

Great. So unless anybody has any objections, I'll plan to do the following on Monday:

• Merge this PR (unless somebody else wants to)
• Tag the new version as 0.6.7
• Upload it to PyPI and conda/binstar

I'm not one of the developers on sourceforge, but I can send Richard or Scott the tarball or you could grab it from PyPI and upload to sourceforge.

All sounds good to me. When we do a new release on SourceForge, we typically send out an e-mail to python-control-announce describing what is new in the release. Scott and I can handle that as well, with input from others if we need help in the descriptions. The e-mail for the last release is here:

http://sourceforge.net/p/python-control/mailman/message/32135649/

Looking back, I see version 0.6a was released in Nov 2012, more than 2 years ago. There have been a lot of changes since then (including changing the version numbering scheme from 0.6d, etc, to 0.6.5, etc), so I'm thinking it makes sense to bump the version to 0.7.0. I'll plan on releasing this as 0.7.0 tomorrow, unless there are any objections.

Sounds sensible.