Use git-based versioning

[brandonwillard]

It looks like this project needs to add commits and Git tags in order to create releases. The process can be made much simpler by using something like versioneer.

[ccordoba12]

We did that before but that doesn't work very well with our workflow at Spyder (where we maintain a copy of this repo to run integration tests).

Besides inflating my and the other maintainers git commits account (which is a bit ugly, but not so bad), what are the disadvantages of our current process?

[brandonwillard]

We did that before but that doesn't work very well with our workflow at Spyder (where we maintain a copy of this repo to run integration tests).

Besides inflating my and the other maintainers git commits account (which is a bit ugly, but not so bad), what are the disadvantages of our current process?

For people pulling from/watching the repo, it adds a lot of unnecessary noise to the Git history, especially since versioning is already sufficiently handled in Git via tags.

Aside from that, it's a very real convenience in terms of project maintenance, since—for instance—it allows maintainers to create releases without requiring rebases in feature branches, it automatically provides version numbers that reflect the state of the code, which can be helpful for remote debugging/error reporting, it facilitates release and build automations, etc.

I don't know your situation at work, so I can't say anything about the challenges imposed by that, nor can I say that using versioneer won't come with its own challenges, but I can say that once things are properly set up, it can work as expected without much/any ongoing work. In other words, the upfront effort to set it up correctly can be offset by the conveniences it provides in the long run.

[ccordoba12]

For people pulling from/watching the repo, it adds a lot of unnecessary noise to the Git history

Well, the new commits are pushed at the exact same time as the release is created, so I don't see any big difference there.

Aside from that, it's a very real convenience in terms of project maintenance,

Sure, but that's the maintainers (i.e. our) choice.

it can work as expected without much/any ongoing work

Sure, as I said, we worked like that before but preferred to switch to manual releases instead.

[brandonwillard]

Well, the new commits are pushed at the exact same time as the release is created, so I don't see any big difference there.

The release timing isn't an issue.

Sure, but that's the maintainers (i.e. our) choice.

That's why I put forth this recommendation: so you can choose to take it, or not.

Sure, as I said, we worked like that before but preferred to switch to manual releases instead.

If there's some complication I'm not aware of, then it might not be a worthwhile action to take, and that's all there is to it.

Regardless, you can always close the issue if you're already decided on this.

[ccordoba12]

This was solved by PR #84 because it added setuptools-scm as a build dependency.