Consider renaming version.py to autover.py?

[ceball]

I think autover.py instead of version.py might provide clearer identification and would be less confusing.

Apart from e.g. packaging's version.py or distutils' version.py, there's something like half a million files on github named version.py: https://github.com/search?utf8=%E2%9C%93&q=filename%3Aversion.py&type= (if I searched right).

[jlstevens]

I think I agree but the problem is that it was version.py in param previously which has implications for backwards compatibility. Unless that file should still exist and just reflects autover.py?

I am very happy to carry out this renaming as soon as a decision is made. I already tried this change briefly but went back to version.py partly to resolve a merge conflict at the time and partially because I think @jbednar was in favor of version.py. I can rename the file as soon as we decide whether or not we should!

[jbednar]

I think it should be version.py in Param, for backwards compatibility, but autover.py otherwise.

[jbednar]

Or we could have it be autover.py, but set version=autover in param/__init__.py to make it available where old packages expect it while making it clearly visible as autover.py.

[jlstevens]

That last suggestions sounds fine to me. @ceball ?

[ceball]

I think it should be version.py in Param, for backwards compatibility

Is autover backwards compatible with param's version.py? I.e. if someone's using param's version.py and then they get a new release of param (in which version.py has changed from how it was to the new autover), will things

1. keep working as before? or
2. keep working, but change in some way (e.g. change their __version__ format, or maybe lack some features such as comparison that were available before)? or
3. stop working, failing with an error? or
4. stop working, with no error?

Originally I thought 4 was true.

However, trying to catch up, it now looks to me like I was wrong, and maybe 2 is true? Is that the case? I.e. for someone who's using param's original version.py and updates to a new param release, things will keep working (without them having to change their workflow), but they'll now get a different version format (and maybe some features have gone)?

[jlstevens]

@ceball This was discussed here

In short, there will be a warning for old-style usage of Version prompting people who used it as param.Version to check it works right (or to upgrade to the new workflow).

[jlstevens]

I think it is option 2:

keep working, but change in some way (e.g. change their version format, or maybe lack some features such as comparison that were available before)? or

But with a warning when a release tuple is specified, not an error.