@c24t can you help me understand why you would bump the version in the repository, but before release time? In a good deal fo the googleapis repositories we use release-tool and release-please, which automate releasing to PyPI, version reving, changelog generation, etc. And as part of that process the version number is updated. This would be a deviation and I'd like to understand how those tools fall short/don't align with your project.

Thanks!

I'd like to understand how those tools fall short/don't align with your project.

We're following (an admittedly odd) convention for django db driver packages here: the major/minor version components have to match the version of django we're targeting, and we only change the micro component. Since we're only targeting django 2.2.x now, our version number also has to be 2.2.x. Later when we target 3.1.x we'll have to maintain a separate branch. We're using release-tool/release-please, but we set the version number manually.

This PR isn't really necessary, just convenient. I think it's helpful to have a different version numbers for the code in the repo and the pip-installable package so you can tell quickly if e.g. a CI script is downloading something from PyPI that it should be installing from source.

In any case I'm happy to leave the version number as-is. Let me know if you've got any suggestions for how we should handle versioning or releases differently.

That all makes sense. Thank you for helping me to better understand. I think if you follow a process where you either

1. rev right before release
2. rev right after release

It should work well, or at least I would think. I couldn't find it but is the process for releasing this written down?

I couldn't find it but is the process for releasing this written down?

It's not written down here. We're using release-please as usual but setting the version number manually with empty "Release-As" commits, like this one: 803ad0a. That commit triggered this release PR with a custom version number: #505.