Please DO NOT upload built distribution wheels without updating the version

[jnhyperion]

For using who're using poetry or similar dependency lock tools, this will cause the lock file out of date without any library version update.

15:34:21  + git diff
15:34:21  diff --git a/poetry.lock b/poetry.lock
15:34:21  index 6129f795..39d2b628 100644
15:34:21  --- a/poetry.lock
15:34:21  +++ b/poetry.lock
15:34:21  @@ -106,6 +106,10 @@ files = [
15:34:21       {file = "Brotli-1.1.0-cp310-cp310-musllinux_1_1_i686.whl", hash = "sha256:a37b8f0391212d29b3a91a799c8e4a2855e0576911cdfb2515487e30e322253d"},
15:34:21       {file = "Brotli-1.1.0-cp310-cp310-musllinux_1_1_ppc64le.whl", hash = "sha256:e84799f09591700a4154154cab9787452925578841a94321d5ee8fb9a9a328f0"},
15:34:21       {file = "Brotli-1.1.0-cp310-cp310-musllinux_1_1_x86_64.whl", hash = "sha256:f66b5337fa213f1da0d9000bc8dc0cb5b896b726eefd9c6046f699b169c41b9e"},
15:34:21  +    {file = "Brotli-1.1.0-cp310-cp310-musllinux_1_2_aarch64.whl", hash = "sha256:5dab0844f2cf82be357a0eb11a9087f70c5430b2c241493fc122bb6f2bb0917c"},
15:34:21  +    {file = "Brotli-1.1.0-cp310-cp310-musllinux_1_2_i686.whl", hash = "sha256:e4fe605b917c70283db7dfe5ada75e04561479075761a0b3866c081d035b01c1"},
15:34:21  +    {file = "Brotli-1.1.0-cp310-cp310-musllinux_1_2_ppc64le.whl", hash = "sha256:1e9a65b5736232e7a7f91ff3d02277f11d339bf34099a56cdab6a8b3410a02b2"},
15:34:21  +    {file = "Brotli-1.1.0-cp310-cp310-musllinux_1_2_x86_64.whl", hash = "sha256:58d4b711689366d4a03ac7957ab8c28890415e267f9b6589969e74b6e42225ec"},
15:34:21       {file = "Brotli-1.1.0-cp310-cp310-win32.whl", hash = "sha256:be36e3d172dc816333f33520154d708a2657ea63762ec16b62ece02ab5e4daf2"},
15:34:21       {file = "Brotli-1.1.0-cp310-cp310-win_amd64.whl", hash = "sha256:0c6244521dda65ea562d5a69b9a26120769b7a9fb3db2fe9545935ed6735b128"},
15:34:21       {file = "Brotli-1.1.0-cp311-cp311-macosx_10_9_universal2.whl", hash = "sha256:a3daabb76a78f829cafc365531c972016e4aa8d5b4bf60660ad8ecee19df7ccc"},

Please avoid doing this.

[anthrotype]

Sorry about that. Last week I triggered the CI on https://github.com/google/brotli-wheels to build and upload wheels for newly released Python 3.13 but that might have also accidentally upload extra wheels for older pythons as you show above.
The version of the Brotli python module as defined in its setup.py is actually sourced from the https://github.com/google/brotli/blob/master/c/common/version.h header so it must be in sync with the embedded C library. If we want to update the version of the python module, the maintainers would also need to make a release to bump the version.
Alternatively, we could allow the python module's version to be decoupled from the lib's version, but then there's the risk they may go out of sync.

/cc @eustas

[eustas]

Hopefully we will have next release this year.

[kurtmckee]

@anthrotype

If we want to update the version of the python module, the maintainers would also need to make a release to bump the version.

Python versioning is more expressive than this.

For example, public version identifiers are defined to simply be any number of dot-separated values, so you could release new versions as:

{brotli_version}.0   -->   1.1.0.0
{brotli_version}.1   -->   1.1.0.1

You could also codify that the first X numbers are your package version, followed by the brotli version, like:

1.1.{brotli_version}   -->   1.1.1.1.0
1.2.{brotli_version}   -->   1.2.1.1.0

In short, the package version doesn't have to be as constrained as it currently is.

[kurtmckee]

After reviewing other issues involving Python 2.7 failures, I think my recommendation here would be to use the first X numbers for your package version, followed by the brotli version.

1.1.0      <-- current package version
1.2.1.1.0  <-- new package version scheme
    ^^^^^
    |
    +-- brotli version embedded in built wheels

Documenting what the numbers mean then allows people to pin their dependencies in the ways that they meaningfully want, like brotli>=1.2,<1.3.