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

TL: bump version to 5.5.2 + added release guide for maintainers #489

Merged
merged 8 commits into from
Sep 23, 2024
Merged
Show file tree
Hide file tree
Changes from 7 commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 3 additions & 0 deletions .github/workflows/ci_pipeline.yml
Original file line number Diff line number Diff line change
Expand Up @@ -4,6 +4,9 @@ name: CI pipeline for pySDC

on:
push:
branches:
- '**'
- '!new-release'
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why this?

Copy link
Member Author

@tlunet tlunet Sep 23, 2024

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 😉 🌍

Copy link
Member

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.

Copy link
Member Author

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)

Copy link
Contributor

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.

Copy link
Member Author

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 ...

Copy link
Contributor

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.

Copy link
Member Author

@tlunet tlunet Sep 23, 2024

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 ...

pull_request:
schedule:
- cron: '1 5 * * 1'
Expand Down
4 changes: 2 additions & 2 deletions CITATION.cff
Original file line number Diff line number Diff line change
Expand Up @@ -30,9 +30,9 @@ authors:
affiliation: "Jülich Supercomputing Centre, Forschungszentrum Jülich GmbH, 52425 Jülich, Germany"


version: 5.5.1
version: 5.5.2
doi: 10.5281/zenodo.594191
date-released: 2024-09-03
date-released: 2024-09-23
keywords:
- "parallel-in-time"
- "spectral deferred corrections"
Expand Down
2 changes: 1 addition & 1 deletion docs/contrib/06_new_project.md
Original file line number Diff line number Diff line change
Expand Up @@ -57,4 +57,4 @@ We strongly encourage to describe and cite the current version of pySDC already

:arrow_left: [Back to Documenting Code](./05_documenting_code.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)
:arrow_right: [Next to publishing a new release](./07_release_guide.md)
38 changes: 38 additions & 0 deletions docs/contrib/07_release_guide.md
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)
2 changes: 1 addition & 1 deletion docs/source/conf.py
Original file line number Diff line number Diff line change
Expand Up @@ -72,7 +72,7 @@
# The short X.Y version.
version = '5.5'
# The full version, including alpha/beta/rc tags.
release = '5.5.1'
release = '5.5.2'

# The language for content autogenerated by Sphinx. Refer to documentation
# for a list of supported languages.
Expand Down
2 changes: 1 addition & 1 deletion pyproject.toml
Original file line number Diff line number Diff line change
Expand Up @@ -4,7 +4,7 @@ build-backend = "flit_core.buildapi"

[project]
name = 'pySDC'
version = '5.5.1'
version = '5.5.2'
description = 'A Python implementation of spectral deferred correction methods and the likes'
license = {text = "BSD-2-Clause"}
readme = 'README.md'
Expand Down
Loading