Change to using automatic versioning from Git tags#213
Conversation
|
If you want to implement auto-versioning using git-tag, please do not forget to update the CONTRIBUTING.md file. |
Good reminder. I will do that when I managed to get it to work. Currently trying to figure out what to do to get the documentation to still build since hatch doesn't seem to automatically add the |
|
@TeresiaOlsson my llm-driven exploration was suggesting to use comittizen with hatch to build automatic versions. |
I think the solution is at this page https://github.com/ofek/hatch-vcs. Trying to use my llm exploration to understand what it actually means what is said about versions on that page ;) |
|
I think I have fixed all problems now. At least all workflows runs successfully. So it's ready to reviewed. |
|
Did you forget to add pyaml/_verion.py ? [tool.hatch.build.hooks.vcs]
version-file = "pyaml/_version.py" |
|
@TeresiaOlsson could you also rename the merge request? So, the name is more descriptive of what you actually did? (automatic versioning) |
As I understand it, it is generated, right? |
|
If it is a generated file, please add it in .gitignore. |
Yes, it's generated. I will add it to .gitignore. |
gupichon
left a comment
There was a problem hiding this comment.
Tested locally. Works fine.
I have added automatic versioning from Git tags in the pyproject.toml. Advantages of this:
There is no hardcoded version number that needs to be manually bumped when making a new release. Instead the release can be built based on a Git tag which simplifies the release workflow.
If you install directly from the Git repository you will get a version number based on the next release number + the commit number making it easier to distinguish between the developer version and the released version. This helps to know which version you have installed when debugging. For example it might look like this in
pip list: