-
Notifications
You must be signed in to change notification settings - Fork 33
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
TL: bump version to 5.5.2 + added release guide for maintainers #489
Merged
Merged
Changes from 7 commits
Commits
Show all changes
8 commits
Select commit
Hold shift + click to select a range
cec3dfc
TL: added release guide
tlunet 6c6d540
TL: additional detail
tlunet 6df08c4
Update 07_release_guide.md
pancetta d4a8760
TL: minor correction on release guide
tlunet 7236ed0
TL: typo
tlunet 8be6bf2
TL: lighter testing
tlunet 15ebe6d
TL: bump version to 5.5.2
tlunet 645cdc6
TL: let's not care
tlunet File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,38 @@ | ||
# Publishing a new release (for maintainers only!) | ||
|
||
## Base conventions | ||
|
||
For each version update (a.k.a **releases**), we use [semantic versioning](https://semver.org/): | ||
|
||
- **patch** (from `*.*.{i}` to `*.*.{i+1}`): minor modifications, bugfixes, code reformating, small new features, new projects or playgrounds, new tests | ||
- **minor** (from `*.{i}.*` to `*.{i+1}.0`): addition of new major features, minor code structure changes without too much impact on the API (backward compatible) | ||
- **major** (from `{i}.*.*` to `{i+1}.0.0`): major changes in code structure, design, and API, with changes potentially breaking backward compatibility | ||
|
||
## Release Pipeline | ||
|
||
First, create a `new-release` branch (or choose a similar name), either on your fork or on the main `pySDC` repo. Then, on commit: | ||
|
||
1. modify the project version number and, if necessary, the list of authors in `pyproject.toml` | ||
2. modify the documentation release number in `docs/source/conf.py`, and the version number for minor and major release. Also, if necessary, adapt the list of authors. | ||
3. modify the version number, release date and, if necessary, the list of authors in `CITATION.cff` | ||
4. (for minor and major release **only**) add the release description in the `CHANGELOG.md` file, following the level of details you can find there | ||
|
||
Commit with the message: `bump version to x.x.x` where `x.x.x` is the new version. | ||
Then create a pull request, and once all tests passed, you can `Merge and Squash`, | ||
possibly adding your initials as prefix of the final commit message. | ||
|
||
> 🔔 Don't forget to delete the `new-release` branch both locally and on your fork (or the main repo): | ||
|
||
```bash | ||
git push -d origin new-release # delete on remote | ||
git branch -D new-release # delete locally | ||
``` | ||
|
||
Finally, [draft a new release](https://github.com/Parallel-in-Time/pySDC/releases/new) associated to a new tag | ||
`v*.*.*` (with `*.*.*` the new version, and the ` + Create new tag: ... on publish` button). | ||
Add a comprehensive summary of the main changes, with appropriate thanks to all the contributors (cf previous releases), and publish it. This will trigger automatically a release update on [Zenodo](https://zenodo.org/doi/10.5281/zenodo.594191). | ||
For uploading the new release on [PyPI](https://pypi.org/project/pySDC/), this is done manually so you'll have to ask [Robert Speck (@pancetta)](https://github.com/pancetta) for support (ideally send him a quick email). | ||
|
||
:arrow_left: [Back to adding Project](./06_new_project.md) --- | ||
:arrow_up: [Contributing Summary](./../../CONTRIBUTING.md) --- | ||
:arrow_right: [Next to a cute picture of cat](https://www.vecteezy.com/photo/2098203-silver-tabby-cat-sitting-on-green-background) |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To avoid running the full tests on a
new-release
branch, since it will be done after once the PR is triggered... saving a bit of energy 😉 🌍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's the harm, though? You don't have to wait for the checks to pass before creating a PR. And if people dare to call their branch differently (see guide), this won't help. It's a special exception with no obvious/explained reason in the pipeline file I'd rather avoid.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, I was originally more in favor of "one name only" for the version bump branch ... and commit on new branches in fork appear to not be tested before the PR is triggered. It just felt a bit like a waste to test every commit we do when modifying the new release branch (e.g for this one, the 6 commits where tested while they shouldn't have)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The website is only built when pushing to master, though, no? So while you do test everything during the PR, the website is only updated to the new version number when the CI runs again after the merge.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm speaking about all the tests (projects, code, ...) that are run for all python version and for all commit that you do on this branch. Those are unnecessary since they will be run once the PR is triggered (when the branch is ready). At the end it wouldn't have change anything, but would have save a bit of energy consumption somewhere in a data-center by avoiding redundant tests.
But well, I chose my fights ...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, I see. Well you may still want to run them in case some versions have changed in a breaking way. And if not you can always just cancel manually. It's not like people are doing new releases every other hour.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That was my point : tests will be run anyway when the PR is triggered, so if the version change breaks the code, you'll see it. Hence you don't need to run those when pushing on this branch before ...