Simplify minor releases so we do them more often

In a recent Zoom discussion with @mandli and @ketch, we discussed simplifying the release procedure for minor releases (e.g. 5.7.1, 5.7.2, …) following each major release (e.g. 5.7.0). We would like to start doing these more frequently so that bug fixes or minor improvements get incorporated in a timely manner.

The current release procedure is summarized in these documents:

• http://www.clawpack.org/howto_release.html
• http://www.clawpack.org/howto_doc.html
• https://github.com/clawpack/clawpack/wiki/Release-procedure (out of date)

Here are some suggestions for further discussion:

1. For minor releases, don’t bother with release candidates unless there’s a need to test things out.

2. For minor releases, create a tar file for https://github.com/clawpack/clawpack/releases/, but do not archive it at Zenodo with a new DOI.

3. Instead of using Zenodo at all, we might also consider using this Open Science Framework (OSF) project I just created, https://osf.io/kmw6h/, which can have a single DOI for the project and allows adding new tar files in the future. This would also simplify our suggested citation to say:

   Clawpack Development Team (2020), Clawpack Version X.Y.Z, 
   http://www.clawpack.org, doi: 10.17605/OSF.IO/KMW6H
   

   without having to update this DOI for every new release. (This seems to partially defeat the purpose of a DOI since it’s possible to change the contents of this project while the DOI is unchanged, but that’s the way it apparently works.)

4. For the documentation, rather than having a new version for each minor release, have the sidebar say e.g. “Version 5.7.x” and assume that any updates to these doc’s will apply to all minor releases. If there’s a substantial change to the documentation there should presumably be a new major release. This will both simplify the release process and also keep the number of past versions of the docs that have to get built manageable, even if we start doing many more minor releases.

5. Documentation for upcoming changes or new features that might be in the master branch of Clawpack but not yet in a release can still go in the dev branch of clawpack/doc.

6. For the release notes on http://www.clawpack.org/releases.html, create a new one for each major release, with some discussion of the new/modified features. In between major releases, have a page like changes to master since 5.7.0 and also maybe a new one “changes from 5.7.0 to 5.7.x” for the current minor release (without separate pages for intervening minor releases), that simply has the links to all the commits from the last major release, and which are automatically generated.

7. To generate the links to commits from the release note pages, and also so that people can check out a particular minor release easily, we should still tag each new minor release in clawpack/clawpack and every submodule with a tag like v5.7.1.

8. Still do a pypi update for each minor release so that pip install clawpack always gets the most recent version?

9. Don’t create new docker files or upload to dockerhub for minor releases.

[ketch]

Thanks! One quick note: Zenodo already provides a single DOI to refer to all versions: 10.5281/zenodo.3764200. This is explained in some small text for instance on this page. I think it would be fine to use that in the citation suggestion in the docs.

This all looks fine to me. I can take 15 minutes to do a pypi release even for minor releases.

[rjleveque]

Many of the other things originally discussed in this issue have already been implemented, such as having a documentation branch v5.9.x and having the OSF version. So I think it’s fine to close this.