should the Python module's version always match the library version?

[anthrotype]

v0.2.0 has been tagged, but the Python package version as stored in python/brotlimodule.cc still says "0.1.0" (see here).
This version string is read by the setup.py, and stored in the package metadata upon installing.

I wonder if the Python module's version should also increase every time a Brotli update is tagged, or if language bindings should have their own version numbers, independent from the core library.

WDYT?

[szabadka]

I think the Python module's version should refer to the version of the underlying Brotli library, but it seems difficult to keep them in sync automatically. Any ideas would be welcome.

If we would do it manually, we would have to remember to bump the version number right before we tag the release, right? Doing it right after would be too late since everything built from the tagged release would have the wrong version number (as with v0.2.0). I will try to remember doing this going forward.

[anthrotype]

here they use a post-commit git hook which automatically adds a new tag whenever the version string is modified.

I don't know if it's worth doing it though.

[szabadka]

It is not clear if this would work if the version is updated through merging a pull request. Anyway, let's try to remember updating the version string before release for now and see if that works. The bro.cc does not have a --version flag yet, before we attempt to do this automation, I want to move the BROTLI_VERSION define to a common place and use it from the bro.cc as well.

[anthrotype]

yes, that sounds good to me. Thanks.

[szabadka]

I created the version.h header in PR #193

Closing this now as the question in the issue was decided.

[anthrotype]

thanks!