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.

Sign up for GitHub

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

Jump to bottom

Updates to cep3 in preparation for releases #339

Open
wants to merge 5 commits into
base: source
Choose a base branch
from
Open

Updates to cep3 in preparation for releases #339

Changes from all commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
5c516d3
remove references to smbchk in cep3
munkm Mar 21, 2024
26d1113
Removed reference to Rickshaw and CyclusJS from The Cyclus Ecosystem
dean-krueger Mar 21, 2024
102ff7b
Merge pull request #1 from dean-krueger/cep3-updates
munkm Mar 21, 2024
3fa64cb
changed language from master branches to main branches
dean-krueger Mar 21, 2024
3aee2b9
Merge pull request #2 from dean-krueger/cep3-updates
munkm Mar 21, 2024
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
75 changes: 19 additions & 56 deletions source/cep/cep3.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -3,7 +3,7 @@ CEP 3 - |Cyclus| Release Procedure

:CEP: 3
:Title: |Cyclus| Release Procedure
:Last-Modified: 2017-11-06
:Last-Modified: 2024-03-21
:Author: Anthony Scopatz and Matthew Gidden and Baptiste Mouginot
:Status: Accepted
:Type: Process
Expand All @@ -29,12 +29,6 @@ stable.) The projects that are under the release manager's purview are:
* `Cycamore`_
* `Cymetric`_

The projects which are not yet under the release managers purview are:

* `Rickshaw`_
* `CyclusJS`_


.. note::

The following full release process only applies to MAJOR and MINOR
Expand All @@ -48,7 +42,7 @@ The projects which are not yet under the release managers purview are:
Release Candidates (Tags & Branches)
====================================
At the beginning of a release, a special branch for *each* project should be
made off of ``master`` named ``vX.X.X-release``. Note the *v* at the beginning. Each
made off of ``main`` named ``vX.X.X-release``. Note the *v* at the beginning. Each
project should have the initial version of of it's release branch *tagged* as
``X.X.X-rc1``, the first release candidate.

Expand All @@ -63,13 +57,13 @@ the project should be encouraged to test them out in order to bugs/other issues.

Any required changes must be pull requested from a topical branch into the
*release* branch. After this has been accepted, the topical branch must be
merged with ``master`` as well. The release branch is there so that development
can continue on the ``master`` branch while the release candidates (rc) are out
merged with ``main`` as well. The release branch is there so that development
can continue on the ``main`` branch while the release candidates (rc) are out
and under review. This is because otherwise any new developments would have to
wait until post-release to be merged into ``master`` to prevent them from
wait until post-release to be merged into ``main`` to prevent them from
accidentally getting released early.

Everything that is in the release branch must also be part of ``master``.
Everything that is in the release branch must also be part of ``main``.
Graphically,

.. figure:: cep-0003-1.svg
Expand All @@ -80,10 +74,10 @@ Graphically,
.. note::

Any commits merged into the release branch must *also* be merged into
``master``. It is common practice for the release manager to request the
reviewer pull requests to merge the topical branch into ``master``
``main``. It is common practice for the release manager to request the
reviewer pull requests to merge the topical branch into ``main``
as well. However, it is the ultimate release manager's responsibility to
make sure ``master`` is kept up to date with the ``release`` branch.
make sure ``main`` is kept up to date with the ``release`` branch.

If changes are made to the release branch, a new candidate must be issued after
*2 - 5 days*. Every time a new release candidate comes out the ``vX.X.X-release``
Expand All @@ -93,7 +87,7 @@ accompany any new candidate.
The release branch must be quiet and untouched for *2 - 5 days prior* to the
full release. When the full and final release happens, the ``vX.X.X-release``
branch is deleted. All commits in the ``vX.X.X-release`` branch must have also
been merged into the ``master`` branch as they were accepted.
been merged into the ``main`` branch as they were accepted.

Project Checklist
=================
Expand All @@ -120,13 +114,13 @@ Release Candidate Process

#. Finish the release candidate process

- make sure all commits in the ``release`` branch also are in ``master``
- make sure all commits in the ``release`` branch also are in ``main``

Release Process
---------------

#. Make sure every local |cyclus| project repository is up to date with its
``master``, and ``vX.X.X-release`` branches on ``upstream``.
``main``, and ``vX.X.X-release`` branches on ``upstream``.

#. Bump the version in ``cyclus/src/version.h.in`` and ``cyclus/cyclus/__init__.py``,
``cycamore/src/cycamore_version.h.in``, and
Expand Down Expand Up @@ -179,21 +173,21 @@ Release Process
$ git checkout vX.X.X-release
$ git commit -am "final release commit after maintenence"

#. Update all master branches.
#. Update all main branches.

.. code-block:: bash

$ cd /path/to/project
$ git checkout master
$ git checkout main
$ git merge --no-ff vX.X.X-release
$ git push upstream master
$ git push upstream main

#. *Locally* tag the repository for *each* of the projects.

.. code-block:: bash

$ cd /path/to/project
$ git checkout master
$ git checkout main
$ git merge --no-ff vX.X.X-release
$ git tag -a -m "Cyclus project release X.X.X, see http://fuelcycle.org/previous/vX.X.X.html for release notes" X.X.X

Expand Down Expand Up @@ -225,12 +219,12 @@ Release Process
$ export CYCAMORE_DIR=/path/to/cycamore
$ ./api_docs.sh X.X.X # X.X.X is *this* version

#. Update the ``master`` branch of all projects and clean up.
#. Update the ``main`` branch of all projects and clean up.

.. code-block:: bash

$ cd /path/to/project
$ git push upstream X.X.X master
$ git push upstream X.X.X main
$ git push upstream --delete vX.X.X-release

#. Manually visit the github.com page for each project and draft/publish a new release.
Expand Down Expand Up @@ -278,7 +272,7 @@ Release Process

.. This part has been commented, as it is required for the website, but the
person in charge of the release might not have the proper access to update the
Dory worker. This should be automated when a merge is done on the master branch
Dory worker. This should be automated when a merge is done on the main branch
a CI-hook should update the dory cloudlus server and relaunch the worker.
Moreover the cloudlus server is not directly related to Cyclus and depend on
the UW-Madison community but the website relies on it to host the
Expand Down Expand Up @@ -351,37 +345,6 @@ Gtest's natural evolution cycle, please download the latest release of Google Te
and follow `the fused source directions here`_. If we go too long without doing this,
it could be very painful to update.

**Verify & Update API Stability:** Since |Cyclus| v1.0 we promise API
stability. Luckily, we have a tool for keeping track of this mostly
automatically. In order to check this correctly, you must have a **RELEASE**
build of Cyclus compiled/installed. Every release please run the following
command to verify that the release branch is stable:

.. code-block:: bash

$ cd cyclus/release
$ ./smbchk.py --update -t HEAD --no-save --check

If |cyclus| only has API additions, it is considered stable and the command will
tell you so. If |cyclus| also has API deletions, then |cyclus| is considered
unstable and a diff of the symbols will be printed.
**You cannot release |cyclus| if it is unstable!** Please post the diff to
either the mailing list or the issue tracker and work to resolve the removed
symbols until it this command declares that |cyclus| is stable. It is
probably best to do this prior to any release candidates if possible.

Once stable and there are no more code changes to be made, add the symbols
in this release to the database with the following command (again - make sure
you are working on a RELEASE build of Cyclus):

.. code-block:: bash

$ cd cyclus/release
$ ./smbchk.py --update -t X.X.X

where ``X.X.X`` is the version tag. This should alter the ``symbols.json``
file. Commit this and add it to the repo.

Cycamore
--------

Expand Down