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

set version using setuptools_scm #479

Merged
merged 9 commits into from
Oct 26, 2022
Merged

set version using setuptools_scm #479

merged 9 commits into from
Oct 26, 2022

Conversation

jmduarte
Copy link
Member

@jmduarte jmduarte commented Dec 25, 2021

  • bump version to 0.6.0
  • add GitHub action to automatically bump patch version on merge of PRs

@vloncar @thesps opening this PR for discussion on how to handle automatic version bumping

My thought is it to have a GitHub action to automatically bump patch version on merge of PRs (unless PR has [MINOR] or [MAJOR] in the comment, then we bump the minor or major version as well)

@vloncar
Copy link
Contributor

vloncar commented Dec 25, 2021

IMO we should move away from hardcoded __version__ attribute and instead use something like setuptools_scm. That way the git tag becomes the version, and this information is available in the package (through the same attribute). Generating the version information this way gets rid of the problems you may have when switching from master to released version. The way it is currently, if we put 0.6.0 in master we may cause some problems to people switching from released version to master branch. The only way to not have problems is to make sure master is always the latest version (like 99.99.99) but this is very ugly. We're already using the new scheme in the QONNX project (pyscaffold sets this up) and I believe we should do the same here.

@jmduarte jmduarte changed the title [WIP] bump version to 0.6.0 and set up GitHub action to automatically bump [WIP] bump version using setuptools_scm Dec 25, 2021
@jmduarte
Copy link
Member Author

Good point, that solution is a lot nicer.

I tried to update it by hand, but it may not be correct yet... For some reason, the autodetection of tags seems off, because if I try

python setup.py --version

in the this branch, I get: 0.5.0.post1.dev184+gc9730ff

@jmduarte
Copy link
Member Author

@vladimir I was looking into migrating the whole package using PyScaffold: https://pyscaffold.org/en/stable/migration.html

See, e.g.: master...jmduarte:pyscaffold

What do you think about this approach?

@jmduarte jmduarte changed the title [WIP] bump version using setuptools_scm set version using setuptools_scm Jun 22, 2022
@jmduarte jmduarte self-assigned this Jun 22, 2022
@jmduarte jmduarte requested a review from thesps June 22, 2022 03:57
@jmduarte
Copy link
Member Author

OK @thesps @vloncar, I figured out why currently on this branch I get an hls4ml version of 0.5.0.post1.dev133+gef0b82bd. Basically, it's because it looks for the closest parent tag and because we created a separate branch and cherry-picked developments for 0.6.0, that tag is not a parent of the current master branch.

So I'd say this PR is ready to be merged, with perhaps a small change that we should also apply a tag of 0.6.1 somewhere on the current master (could be this commit as well), that way all versions downstream of this commit will be 0.6.1.post1... (until we tag a new version off of master).

This also means we should probably make sure to explicitly tag versions of master. And for "bleeding edge" developments, we should perhaps create a new dev branch

@jmduarte jmduarte mentioned this pull request Oct 25, 2022
3 tasks
@jmitrevs
Copy link
Contributor

I am partial to switching to version_scheme = "release-branch-semver". This way, if you merge this into main, the main repository becomes hls4ml-0.6.0.dev192+g163e757d.d20221025. We had a release branch for 0.6.0, and I think we can continue that scheme. It's useful for being able to do bug fixes to stable releases. Nevertheless, I am open to other suggestions, since I am not an expert in this area.

@jmitrevs
Copy link
Contributor

Provided the CI tests succeed, I would propose merging this, maybe tomorrow.

setup.cfg Outdated Show resolved Hide resolved
@vloncar vloncar merged commit d31d938 into main Oct 26, 2022
@jmduarte jmduarte deleted the bump_version branch October 27, 2022 13:25
calad0i pushed a commit to calad0i/hls4ml that referenced this pull request Jul 1, 2023
* bump version

* add pyproject.toml

* update

* update

* update

* gitignore update

* try different scheme

* lower tolerance pytest

* Update setup.cfg
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants