Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wrong version metadata in the 4.2.0 release #122

Closed
ocefpaf opened this issue Nov 4, 2024 · 3 comments
Closed

Wrong version metadata in the 4.2.0 release #122

ocefpaf opened this issue Nov 4, 2024 · 3 comments
Labels
enhancement great new idea

Comments

@ocefpaf
Copy link

ocefpaf commented Nov 4, 2024

The latest 4.2.0 release reports itself as 4.1.1.dev0. See

version = "4.1.1-dev0"

This breaks build tools that requires pip-check to ensure version consistency.

@Cube707
Copy link
Collaborator

Cube707 commented Nov 4, 2024

the github has always reported a *-dev version and only the pypi releases get deployed with the full release-version, so this is not new.

But I am willing to work towards a solution for this

@Cube707 Cube707 added the enhancement great new idea label Nov 4, 2024
@ocefpaf
Copy link
Author

ocefpaf commented Nov 4, 2024

the github has always reported a *-dev version and only the pypi releases get deployed with the full release-version, so this is not new.

That is fine for the code that is on main but the released tarball, anywhere it lives, it would be nice to reflect the version of the taf.

But I am willing to work towards a solution for this

I like setuptools-scm for that. After setting it up, all you need to do is to tag a release.

PS: While I'd like to have a stable release in tagged versions, b/c this is by design, feel free to close it if you want. We can try to use the PyPI tarball.

@Cube707
Copy link
Collaborator

Cube707 commented Nov 4, 2024

I'd like to have a stable release in tagged versions, b/c this is by design, feel free to close it if you want

As users can install using pip install git+https://github.com/magmax/python-readchar@v4.2.0 they should get the correct version displayed there, which is currently broken. so I will implement a fix in the coming days

@Cube707 Cube707 closed this as completed in 821ccec Nov 4, 2024
Cube707 added a commit that referenced this issue Nov 4, 2024
To ensure we have the proper version-strings in the tar-balls and other install forms,
we now create two commits automatically. One which contestants the release-version,
where the tag will also be places, and the one containing the dev-increment, as currently.

closes #122
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement great new idea
Projects
None yet
Development

No branches or pull requests

2 participants