Release V5.2.0

[ZedThree]

This has been way too long!

Making a New Release of BOUT++

This is checklist of things to do (in order) when making a new
release. This applies equally to both major/minor releases and bugfix
releases

• Check there are no open issues/PRs for this milestone
  • Fix or bump to next version
• Make a branch named vX.Y.Z-rc
  • The GitHub repo is setup to protect branches named in this style
  • Major and minor release points (X/Y) should be off
    next. Bugfix releases (Z) should be off master
• Make pull request into master
  • Any new bugfixes should be PRs into the RC branch, where
    "bugfixes" can include:
    • silencing warnings
    • improving documentation
    • adding tests
• Run make check-all
  • Raise issues for any tests that fail
• Possibly run clang-tidy, clang-check, coverity, etc.
• Review pinned pip package versions for CI
• Review bundled libraries

Before merging PR:

• Update locale translation files
  • make -C locale update-all
  • Be aware that this will update the timestamps and possibly
    reorder file paths in the .po and .pot files
• Update CHANGELOG.md:
  • Run [bout-changelog-generator.py LAST_RELEASE NEXT_RELEASE][bin/bout-changelog-generator.py]
    • See the docs for how to get the token
• Run [update_citations.py][bin/update_citations.py] to add new
  authors to CITATION.cff
• Prep a new Zenodo release:
  • https://doi.org/10.5281/zenodo.1423212
  • "New Version"
  • "Reserve DOI" -> copy DOI
  • Add any new authors
  • Save draft
• Change DOI in CITATION.cff to new DOI
• Change DOI in README.md to new DOI
• Change date-released in CITATION.cff
• Check abidiff to see if soname needs bumping in makefile:
  • This segfaulted
• Run [update_version_number.py LAST_RELEASE NEXT_RELEASE][bin/update_version_number.py]
• Update what version of PETSc and SUNDIALS we support (upper bound)

After PR is merged:

• Make tarball: make dist from build directory. Ensure you are on a tag and correct version is used for archive and folder within.
• Try to summarise the changes!
• Make GitHub Release, include change summary NB: tag should have
  leading v
• Make tarball: cmake -S . -B build && make dist -C build
• Check tarball:
  • Is the folder name correct?
  • grep for the version - is always the released version used, not a pre-release?
• Upload tarball to GitHub Release
• Upload tarball to Zenodo and publish new version
• Email BOUT++ User Group mailing list, include change summary
• Make news post on project website, include change summary
• Update downloads page
• PR master into next
• Bump version number and add prerelease tag in:
  • configure.ac: AC_INIT
  • CITATION.cff: version
  • manual/sphinx/conf.py: version and release
  • manual/doxygen/Doxyfile_readthedocs: PROJECT_NUMBER
  • manual/doxygen/Doxyfile: PROJECT_NUMBER
  • CMakeLists.txt: _bout_previous_version, _bout_next_version
  • tools/pylib/_boutpp_build/backend.py: _bout_previous_version, _bout_next_version

[ZedThree]

Note that there are some breaking changes in this release, but I don't think they should cause problems for very many people:

• The autotools ./configure build system has been removed
• Parsing of booleans has changed [More consistent parsing of boolean inputs (Breaking change) #2828][https://github.com/More consistent parsing of boolean inputs (Breaking change) #2828] ([bendudson][https://github.com/bendudson]).
  See the manual page for details.
• Previously, the Solver implementations passed the loop counter to
  the iter argument of call_monitors, but since the iteration has
  already been completed when the monitors are called, this results in
  iter always being one less than the number of completed
  monitor-steps at the point when the moniters are called, which is
  confusing. Now, monitors are called with the current number of
  completed monitor-steps.

[ZedThree]

clang-tidy-review can't deal with this many files, maybe we should explicitly disable it for release PRs?

[dschwoerer]

Thanks @ZedThree

We probably should not run clang-format and clang-tidy-review on *-rc branches
I think we do not want to add a potentially large formatting to the release, and also clang-tidy should have been addressed in the individual PRs. Adding it here is likely only noise (if it would work)

Will there also be a 5.1.1 5.1.2 release?
If not, we could just skip maintaining the master branch, which would simplify things 😇

[ZedThree]

We probably should not run clang-format and clang-tidy-review on *-rc branches I think we do not want to add a potentially large formatting to the release, and also clang-tidy should have been addressed in the individual PRs. Adding it here is likely only noise (if it would work)

Yes, agreed!

Will there also be a 5.1.1 5.1.2 release? If not, we could just skip maintaining the master branch, which would simplify things 😇

Yeah, I was thinking we should maybe simplify things and just have main and do all PRs into that. @bendudson thoughts?

[dschwoerer]

We probably should not run clang-format and clang-tidy-review on *-rc branches I think we do not want to add a potentially large formatting to the release, and also clang-tidy should have been addressed in the individual PRs. Adding it here is likely only noise (if it would work)

Yes, agreed!

We seem to have guards, but for some reason they are not working:
https://github.com/boutproject/BOUT-dev/blob/master/.github/workflows/clang-tidy-review.yml#L8
They are in master, next and this PR, so a bit confused why they do not work.

RTFM :-) That will only prevent running the CI for PRs into -rc branches 😓

Will there also be a 5.1.1 5.1.2 release? If not, we could just skip maintaining the master branch, which would simplify things 😇

Yeah, I was thinking we should maybe simplify things and just have main and do all PRs into that. @bendudson thoughts?

Unless we manage to hugely simplify the release workflow, I think it is not worth it.
We often do the patch level only when a new minor release is out, at which point most probably switch to the newest.

[ZedThree]

Unless we manage to hugely simplify the release workflow, I think it is not worth it.

The big advantage is we would only have one branch to care about!

[ZedThree]

We're almost warning clean again, just down to the deprecated FieldGenerator::generate(BoutReal, BoutReal, BoutReal, BoutReal). I completely forget the reasoning behind this one

[dschwoerer]

We probably want #3166 so that the released package gets pushed to pypi.
I guess I have to rebase + new PR?

[ZedThree]

We probably want #3166 so that the released package gets pushed to pypi. I guess I have to rebase + new PR?

I merged the master version already :)

[ZedThree]

@bendudson @dschwoerer Unless there are any objections, I'll merge and release this on Friday

[ZedThree]

For some reason the Fedora push build hung on test-cyclic -- think this must be a runner issue.

I'm going to bump the DOI and make the release now