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

Better versioning for BOUT++ #2595

Merged
merged 4 commits into from
Nov 2, 2022
Merged

Better versioning for BOUT++ #2595

merged 4 commits into from
Nov 2, 2022

Conversation

dschwoerer
Copy link
Contributor

@dschwoerer dschwoerer commented Oct 4, 2022

Inspired by setuptools_scm

CMakeLists.txt Outdated Show resolved Hide resolved
CMakeLists.txt Outdated Show resolved Hide resolved
dschwoerer and others added 2 commits October 4, 2022 11:40
Co-authored-by: David Dickinson <d7919@users.noreply.github.com>
@dschwoerer
Copy link
Contributor Author

Thanks @d7919

bendudson
bendudson previously approved these changes Oct 14, 2022
@ZedThree
Copy link
Member

ZedThree commented Oct 14, 2022

Thanks @dschwoerer, I finally found some time to have a play with this! This still needs manual bumping of the versions inside the sed command when we release a new version?

EDIT: Could we pull out the v4.0.0 and 5.0.0.alpha into PREVIOUS_VERSION and NEW_VERSION variables?

Making it fall back to the hardcoded version if the git command fails is a neat touch.

One could imagine calling out to another tool to work out the version. In fact, setuptools_scm can actually be called from the command line 🤔
That would need some faff making sure it was installed though, and adding a pyproject.toml to configure it, etc. Looks like it's MIT licensed, so we could just pull out all the bits we need and hardcode our config.

But that can wait for a future PR, this works well for now.

@dschwoerer
Copy link
Contributor Author

I actually tried setuptools_scm - but that would only bump to 4.4.$(n+1).dev - and there is no option to get 5.0.0.dev - only 5.1.0 or 5.0.1.dev, haven't tested, not sure. The issue is here: pypa/setuptools_scm#523
But that wouldn't work nice, because if we than merge 4.5 into next, it would use that instead of 5.0.0dev, Anyway, I wouldn't know how to programmatically decide on whether this is going to 5.0.0 or 4.5.0 or 4.4.x ...

So, yes, unfortunately, it needs manual bumping.

I think setting BOUT_PREVIOUS_VERSION and BOUT_NEXT_VERSION might be nicer 👍

@dschwoerer
Copy link
Contributor Author

We will need pyproject.toml at some point, "just" need to get make wheel working 😀

@ZedThree
Copy link
Member

Ah, good point. That is a bit of a shame. Also very true that we just decide what the next version will be, and don't really use an algorithm. Nevermind, this is still nice!

@ZedThree
Copy link
Member

I've changed the hardcoded versions to variables, and updated the release checklist to reflect this.

I did consider making the variables settable from the command line (by making them cache variables), which would make it easier to test and change the variables for maintainers, but would probably cause more problems than it would solve when the version doesn't update automatically.

@ZedThree
Copy link
Member

This can go in as soon as the tests complete

@ZedThree ZedThree merged commit 603f742 into next Nov 2, 2022
@ZedThree ZedThree deleted the versioning branch November 2, 2022 13:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants