Update release procedure, keep CHANGELOG up-to-date (#31969)
Co-authored-by: Harmen Stoppels <harmenstoppels@gmail.com>
This commit is contained in:
parent
d475306b6e
commit
b61187455a
2 changed files with 43 additions and 5 deletions
27
CHANGELOG.md
27
CHANGELOG.md
|
@ -1,3 +1,21 @@
|
||||||
|
# v0.18.1 (2022-07-19)
|
||||||
|
|
||||||
|
### Spack Bugfixes
|
||||||
|
* Fix several bugs related to bootstrapping (#30834,#31042,#31180)
|
||||||
|
* Fix a regression that was causing spec hashes to differ between
|
||||||
|
Python 2 and Python 3 (#31092)
|
||||||
|
* Fixed compiler flags for oneAPI and DPC++ (#30856)
|
||||||
|
* Fixed several issues related to concretization (#31142,#31153,#31170,#31226)
|
||||||
|
* Improved support for Cray manifest file and `spack external find` (#31144,#31201,#31173,#31186)
|
||||||
|
* Assign a version to openSUSE Tumbleweed according to the GLIBC version
|
||||||
|
in the system (#19895)
|
||||||
|
* Improved Dockerfile generation for `spack containerize` (#29741,#31321)
|
||||||
|
* Fixed a few bugs related to concurrent execution of commands (#31509,#31493,#31477)
|
||||||
|
|
||||||
|
### Package updates
|
||||||
|
* WarpX: add v22.06, fixed libs property (#30866,#31102)
|
||||||
|
* openPMD: add v0.14.5, update recipe for @develop (#29484,#31023)
|
||||||
|
|
||||||
# v0.18.0 (2022-05-28)
|
# v0.18.0 (2022-05-28)
|
||||||
|
|
||||||
`v0.18.0` is a major feature release.
|
`v0.18.0` is a major feature release.
|
||||||
|
@ -199,6 +217,15 @@
|
||||||
* 337 committers to packages
|
* 337 committers to packages
|
||||||
* 85 committers to core
|
* 85 committers to core
|
||||||
|
|
||||||
|
# v0.17.3 (2022-07-14)
|
||||||
|
|
||||||
|
### Spack bugfixes
|
||||||
|
|
||||||
|
* Fix missing chgrp on symlinks in package installations (#30743)
|
||||||
|
* Allow having non-existing upstreams (#30744, #30746)
|
||||||
|
* Fix `spack stage` with custom paths (#30448)
|
||||||
|
* Fix failing call for `spack buildcache save-specfile` (#30637)
|
||||||
|
* Fix globbing in compiler wrapper (#30699)
|
||||||
|
|
||||||
# v0.17.2 (2022-04-13)
|
# v0.17.2 (2022-04-13)
|
||||||
|
|
||||||
|
|
|
@ -965,8 +965,13 @@ completed, the steps to make the point release are:
|
||||||
|
|
||||||
$ git checkout releases/v0.15
|
$ git checkout releases/v0.15
|
||||||
|
|
||||||
|
#. If a pull request to the release branch named ``Backports vX.Y.Z`` is not already
|
||||||
|
in the project, create it. This pull request ought to be created as early as
|
||||||
|
possible when working on a release project, so that we can build the release
|
||||||
|
commits incrementally, and identify potential conflicts at an early stage.
|
||||||
|
|
||||||
#. Cherry-pick each pull request in the ``Done`` column of the release
|
#. Cherry-pick each pull request in the ``Done`` column of the release
|
||||||
project board onto the release branch.
|
project board onto the ``Backports vX.Y.Z`` pull request.
|
||||||
|
|
||||||
This is **usually** fairly simple since we squash the commits from the
|
This is **usually** fairly simple since we squash the commits from the
|
||||||
vast majority of pull requests. That means there is only one commit
|
vast majority of pull requests. That means there is only one commit
|
||||||
|
@ -991,7 +996,7 @@ completed, the steps to make the point release are:
|
||||||
|
|
||||||
It is important to cherry-pick commits in the order they happened,
|
It is important to cherry-pick commits in the order they happened,
|
||||||
otherwise you can get conflicts while cherry-picking. When
|
otherwise you can get conflicts while cherry-picking. When
|
||||||
cherry-picking onto a point release, look at the merge date,
|
cherry-picking look at the merge date,
|
||||||
**not** the number of the pull request or the date it was opened.
|
**not** the number of the pull request or the date it was opened.
|
||||||
|
|
||||||
Sometimes you may **still** get merge conflicts even if you have
|
Sometimes you may **still** get merge conflicts even if you have
|
||||||
|
@ -1012,15 +1017,19 @@ completed, the steps to make the point release are:
|
||||||
branch if neither of the above options makes sense, but this can
|
branch if neither of the above options makes sense, but this can
|
||||||
require a lot of work. It's seldom the right choice.
|
require a lot of work. It's seldom the right choice.
|
||||||
|
|
||||||
#. Bump the version in ``lib/spack/spack/__init__.py``.
|
#. When all the commits from the project board are cherry-picked into
|
||||||
|
the ``Backports vX.Y.Z`` pull request, you can push a commit to:
|
||||||
|
|
||||||
#. Update ``CHANGELOG.md`` with a list of the changes.
|
1. Bump the version in ``lib/spack/spack/__init__.py``.
|
||||||
|
2. Update ``CHANGELOG.md`` with a list of the changes.
|
||||||
|
|
||||||
This is typically a summary of the commits you cherry-picked onto the
|
This is typically a summary of the commits you cherry-picked onto the
|
||||||
release branch. See `the changelog from 0.14.1
|
release branch. See `the changelog from 0.14.1
|
||||||
<https://github.com/spack/spack/commit/ff0abb9838121522321df2a054d18e54b566b44a>`_.
|
<https://github.com/spack/spack/commit/ff0abb9838121522321df2a054d18e54b566b44a>`_.
|
||||||
|
|
||||||
#. Push the release branch to GitHub.
|
#. Merge the ``Backports vX.Y.Z`` PR with the **Rebase and merge** strategy. This
|
||||||
|
is needed to keep track in the release branch of all the commits that were
|
||||||
|
cherry-picked.
|
||||||
|
|
||||||
#. Make sure CI passes on the release branch, including:
|
#. Make sure CI passes on the release branch, including:
|
||||||
|
|
||||||
|
@ -1039,6 +1048,8 @@ completed, the steps to make the point release are:
|
||||||
|
|
||||||
#. Follow the steps in :ref:`announcing-releases`.
|
#. Follow the steps in :ref:`announcing-releases`.
|
||||||
|
|
||||||
|
#. Submit a PR to update the CHANGELOG in the `develop` branch
|
||||||
|
with the addition of this point release.
|
||||||
|
|
||||||
.. _publishing-releases:
|
.. _publishing-releases:
|
||||||
|
|
||||||
|
|
Loading…
Reference in a new issue