fix: Bump version ahead of lateset release

[c24t]

Update to avoid having the same version number in this repo as on PyPI.

In general we can handle version number updates one of two ways: (1) change the version number as part of the release commit that produces the GH and PyPI releases or (2) change the version number immediately after the release to the next one we expect to release. In either case we could add a "dev" segment to the version number, but that involves an extra manual step since we're not (yet) using release branches.

This PR changes the versioning scheme from (1) to (2). Note that the next release may be 2.2.1b0 instead, but this still solves the problem that the version in the repo matches the one on PyPI.

[crwilcox]

@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!

[c24t]

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.

[crwilcox]

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?

[c24t]

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.