releases: document releases/latest
tag (#17402)
We got rid of `master` after #17377, but users still want a way to get the latest stable release without knowing its number. We've added a `releases/latest` tag to replace what was once `master`. Co-authored-by: Massimiliano Culpo <massimiliano.culpo@gmail.com>
This commit is contained in:
parent
650ab563f4
commit
b0506a722e
2 changed files with 61 additions and 32 deletions
|
@ -97,6 +97,8 @@ change the way Spack concretizes dependencies within a release branch.
|
|||
So, you can base your Spack deployment on a release branch and `git pull`
|
||||
to get fixes, without the package churn that comes with `develop`.
|
||||
|
||||
The latest release is always available with the `releases/latest` tag.
|
||||
|
||||
See the [docs on releases](https://spack.readthedocs.io/en/latest/developer_guide.html#releases)
|
||||
for more details.
|
||||
|
||||
|
|
|
@ -557,8 +557,10 @@ packages. They should generally only contain fixes to the Spack core.
|
|||
|
||||
Both major and minor releases are tagged. After each release, we merge
|
||||
the release branch back into ``develop`` so that the version bump and any
|
||||
other release-specific changes are visible in the mainline (see
|
||||
:ref:`merging-releases-to-develop`).
|
||||
other release-specific changes are visible in the mainline. As a
|
||||
convenience, we also tag the latest release as ``releases/latest``,
|
||||
so that users can easily check it out to get the latest
|
||||
stable version. See :ref:`merging-releases` for more details.
|
||||
|
||||
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
@ -641,7 +643,7 @@ for a major release, the steps to make the release are as follows:
|
|||
|
||||
#. Follow the steps in :ref:`publishing-releases`.
|
||||
|
||||
#. Follow the steps in :ref:`merging-releases-to-develop`.
|
||||
#. Follow the steps in :ref:`merging-releases`.
|
||||
|
||||
#. Follow the steps in :ref:`announcing-releases`.
|
||||
|
||||
|
@ -744,7 +746,7 @@ release:
|
|||
|
||||
#. Follow the steps in :ref:`publishing-releases`.
|
||||
|
||||
#. Follow the steps in :ref:`merging-releases-to-develop`.
|
||||
#. Follow the steps in :ref:`merging-releases`.
|
||||
|
||||
#. Follow the steps in :ref:`announcing-releases`.
|
||||
|
||||
|
@ -794,19 +796,22 @@ Publishing a release on GitHub
|
|||
for ``download_count`` to see this.
|
||||
|
||||
|
||||
.. _merging-releases-to-develop:
|
||||
.. _merging-releases:
|
||||
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
Merging back into ``develop``
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
Updating `develop` and `releases/latest`
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Once each release is complete, make sure that it is merged back into
|
||||
We merge each release into ``develop``, we tag the latest release as
|
||||
``releases/latest``.
|
||||
|
||||
#. Once each release is complete, make sure that it is merged back into
|
||||
``develop`` with a merge commit:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ git checkout develop
|
||||
$ git merge --no-ff releases/v0.15
|
||||
$ git merge --no-ff releases/vX.Y # vX.Y is the new release's branch
|
||||
$ git push
|
||||
|
||||
We merge back to ``develop`` because it:
|
||||
|
@ -834,6 +839,28 @@ the release is complete and tagged. If you do it before you've tagged the
|
|||
release and later decide you want to tag some later commit, you'll need
|
||||
to merge again.
|
||||
|
||||
#. If the new release is the **highest** Spack release yet, you should
|
||||
also tag it as ``releases/latest``. For example, suppose the highest
|
||||
release is currently ``0.15.3``:
|
||||
|
||||
* If you are releasing ``0.15.4`` or ``0.16.0``, then you should tag
|
||||
it with ``releases/latest``, as these are higher than ``0.15.3``.
|
||||
|
||||
* If you are making a new release of an **older** major version of
|
||||
Spack, e.g. ``0.14.4``, then you should not tag it as
|
||||
``releases/latest`` (as there are newer major versions).
|
||||
|
||||
To tag ``releases/latest``, do this:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ git checkout releases/vX.Y # vX.Y is the new release's branch
|
||||
$ git tag --force releases/latest
|
||||
$ git push --tags
|
||||
|
||||
The ``--force`` argument makes ``git`` overwrite the existing
|
||||
``releases/latest`` tag with the new one.
|
||||
|
||||
|
||||
.. _announcing-releases:
|
||||
|
||||
|
|
Loading…
Reference in a new issue