Add git commit sha to displayed version (useful when running from source) #148
Comments
|
No, bumping versions before a release causes all sorts of problems later. People start using a HEAD version for some bug fix then later think they are running the later release and report against it. The best way to handle this is with a VCS versioning system that shows the exact commit with the last release tag + N commits + commit sha. If this project doesn't want to adopt an SCM aware automated version tag then saving the bump until just before release is the right way to go. |
You mean after?
Could Github actions be used to synchronize the release and the code change? |
No, I meant before, but more specifically long before. The version bump should be at or immediately prior to the release tag, not long before (e.g. at the very end of the dev cycle not the beginning).
Yes, but that's also unnecessary. The correct way to handle this is to remove the version info from the code entirely and rely on a build system that deduces it from the repo tags on every build. This can be done both for Git based source builds and tarballs if done correctly, but takes a bit of careful tooling. |
|
Thanks for clarifying! |
I agree, this is a good common practice. |
fedelibre
changed the title
|
Since this project uses Python's setuptools build system, the logical step would be to adapt the versioning using setuptools_scm and adjust the release workflow around that. |
Modern Python packaging standards rely on static metadata in pyproject.toml rather than dynamic metadata in setup.py. Porting notes: - In modern packaging, console scripts are installed via entry points. The bin/ directory containing the ly and ly-server scripts is removed; instead, entry points specify a module and function to run, and pip automatically creates a wrapper script when installing the project. - The pkginfo is trimmed down to contain only the version. This is because pyproject.toml is not Python code, and the ways in which it can read metadata dynamically are limited. The conf.py file for Sphinx now declares the metadata as well; this might be considered duplication, but things like the name 'python-ly' and the author 'Wilbert Berendsen' are unlikely to change. - There are now a few more URLs in the [project.urls] table. - This does not use setuptools_scm to display the version, but that could be done in the future (see frescobaldi#148). However, getting the version for conf.py needs having the package installed, so this will impose certain constraints for developers. - This change was tested by executing "python -m build" before and after, unpacking the sdists, and checking that the differences were intended.
Modern Python packaging standards rely on static metadata in pyproject.toml rather than dynamic metadata in setup.py, which is considered deprecated. Porting notes: - In modern packaging, console scripts are installed via entry points. The bin/ directory containing the ly and ly-server scripts is removed; instead, entry points specify a module and function to run, and pip automatically creates a wrapper script when installing the project. - The pkginfo is trimmed down to contain only the version. This is because pyproject.toml is not Python code, and the ways in which it can read metadata dynamically are limited. The conf.py file for Sphinx now declares the metadata as well; this might be considered duplication, but things like the name 'python-ly' and the author 'Wilbert Berendsen' are unlikely to change. - There are now a few more URLs in the [project.urls] table. - This does not use setuptools_scm to display the version, but that could be done in the future (see frescobaldi#148). However, getting the version for conf.py needs having the package installed, so this will impose certain constraints for developers. - This change was tested by executing "python -m build" before and after, unpacking the sdists, and checking that the differences were intended.
Modern Python packaging standards rely on static metadata in pyproject.toml rather than dynamic metadata in setup.py, which is considered deprecated. Porting notes: - In modern packaging, console scripts are installed via entry points. The bin/ directory containing the ly and ly-server scripts is removed; instead, entry points specify a module and function to run, and pip automatically creates a wrapper script when installing the project. - The pkginfo is trimmed down to contain only the version. This is because pyproject.toml is not Python code, and the ways in which it can read metadata dynamically are limited. The conf.py file for Sphinx now declares the metadata as well; this might be considered duplication, but things like the name 'python-ly' and the author 'Wilbert Berendsen' are unlikely to change. - There are now a few more URLs in the [project.urls] table. - This does not use setuptools_scm to display the version, but that could be done in the future (see #148). However, getting the version for conf.py needs having the package installed, so this will impose certain constraints for developers. - This change was tested by executing "python -m build" before and after, unpacking the sdists, and checking that the differences were intended.
Modern Python packaging standards rely on static metadata in pyproject.toml rather than dynamic metadata in setup.py, which is considered deprecated. Porting notes: - In modern packaging, console scripts are installed via entry points. The bin/ directory containing the ly and ly-server scripts is removed; instead, entry points specify a module and function to run, and pip automatically creates a wrapper script when installing the project. - The pkginfo is trimmed down to contain only the version. This is because pyproject.toml is not Python code, and the ways in which it can read metadata dynamically are limited. The conf.py file for Sphinx now declares the metadata as well; this might be considered duplication, but things like the name 'python-ly' and the author 'Wilbert Berendsen' are unlikely to change. - There are now a few more URLs in the [project.urls] table. - This does not use setuptools_scm to display the version, but that could be done in the future (see frescobaldi#148). However, getting the version for conf.py needs having the package installed, so this will impose certain constraints for developers. - This change was tested by executing "python -m build" before and after, unpacking the sdists, and checking that the differences were intended.
Looking at the git history, the version bump is usually made just before a new release.
IMO the version bump should be made after a release (of course, for the next unreleased version). Why? Two main reasons:
@PeterBjuhr What do you think? Can you do the version bump?
The text was updated successfully, but these errors were encountered: