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

Development versions should have a distinct version number #687

Open
szhorvat opened this issue Jun 30, 2023 · 3 comments
Open

Development versions should have a distinct version number #687

szhorvat opened this issue Jun 30, 2023 · 3 comments
Assignees
Labels

Comments

@szhorvat
Copy link
Member

Can we please have distinct version numbers for development versions? For example, the current main branch could show 0.10.4.bignumber where bignumber is something derived from the present git commit. Right now it simply shows 0.10.4.

When looking at #685, at one point I was under the impression that I was running 0.10.4 while in reality I was using the dev version.

@szhorvat szhorvat modified the milestone: 0.10.5 Jun 30, 2023
@ntamas
Copy link
Member

ntamas commented Jun 30, 2023

I'll probably look into this, but it seems like this would also involve officially dropping support for Python 3.7. (Python 3.7 has reached EOL three days ago, so in theory we could drop support for it right now and it wouldn't go against our own policies).

The reason is that igraph's version number currently comes from src/igraph/version.py, which is read by setup.py during the process when the library is installed. What you ask for would involve dynamically re-writing src/igraph/version.py based on info from the VCS, during installatin time, which feels like a mess to me. Python 3.8 introduced a way to retrieve the version number of a package from the package metadata (see importlib.metadata.version()), but this is not available in Python 3.7 yet. Once we drop support for Python 3.7, we can re-implement src/igraph/version.py using importlib.metadata.version() and then there would be only one place where we need to update the version number: in pyproject.toml, probably using setuptools_scm. However, extensive testing is needed to ensure that setuptools_scm can come up with a reasonable version number even for rep archive tarballs downloaded directly from Github.

@szhorvat
Copy link
Member Author

szhorvat commented Jun 30, 2023

I added the milestone by accident, this doesn't need to be done now. Let's do it only when we're ready. It's not worth dropping support for old versions just because of this one issue, not even if that Python version is out of support.

@stale
Copy link

stale bot commented Sep 18, 2023

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. Thank you for your contributions.

@stale stale bot added the stale label Sep 18, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants