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

New Issue

claunia · 2026-01-29T20:28:58Z

claunia commented

2026-01-29 20:28:58 +00:00

Originally created by @anthrotype on GitHub (Sep 8, 2015).

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?

Originally created by @anthrotype on GitHub (Sep 8, 2015). [v0.2.0](https://github.com/google/brotli/releases/tag/v0.2.0) has been tagged, but the Python package version as stored in `python/brotlimodule.cc` still says "0.1.0" (see [here](https://github.com/google/brotli/blob/master/python/brotlimodule.cc#L12)). 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?

claunia closed this issue

2026-01-29 20:28:59 +00:00

claunia commented

2026-01-29 20:29:00 +00:00

@szabadka commented on GitHub (Sep 11, 2015):

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.

@szabadka commented on GitHub (Sep 11, 2015): 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.

claunia commented

2026-01-29 20:29:01 +00:00

@anthrotype commented on GitHub (Sep 11, 2015):

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.

@anthrotype commented on GitHub (Sep 11, 2015): [here](https://coderwall.com/p/mk18zq/automatic-git-version-tagging-for-npm-modules) 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.

claunia commented

2026-01-29 20:29:02 +00:00

@szabadka commented on GitHub (Sep 11, 2015):

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.

@szabadka commented on GitHub (Sep 11, 2015): 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.

claunia commented

2026-01-29 20:29:03 +00:00

@anthrotype commented on GitHub (Sep 11, 2015):

yes, that sounds good to me. Thanks.

@anthrotype commented on GitHub (Sep 11, 2015): yes, that sounds good to me. Thanks.

claunia commented

2026-01-29 20:29:06 +00:00

@szabadka commented on GitHub (Oct 2, 2015):

I created the version.h header in PR #193

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

@szabadka commented on GitHub (Oct 2, 2015): I created the version.h header in PR #193 Closing this now as the question in the issue was decided.

claunia commented