1 .. _frr-release-procedure:
6 ``<version>`` - version to be released, e.g. 7.3
7 ``origin`` - FRR upstream repository
9 1. Checkout ``dev/<version>``.
11 .. code-block:: console
13 git checkout dev/<version>
15 2. Create and push a new branch called ``stable/<version>`` based on the
16 ``dev/<version>`` branch.
18 .. code-block:: console
20 git checkout -b stable/<version>
21 git push origin stable/<version>:refs/heads/stable/<version>
23 3. Remove the development branch called ``dev/<version>``
25 .. code-block:: console
27 git push origin --delete dev/<version>
29 4. Update Changelog for Red Hat Packages:
31 Edit :file:`redhat/frr.spec.in` and look for the ``%changelog`` section:
33 - Change last (top of list) entry from ``%{version}`` to the **last**
34 released version number. For example, if ``<version>`` is ``7.3`` and the
35 last public release was ``7.2``, you would use ``7.2``, changing the file
38 * Tue Nov 7 2017 Martin Winter <mwinter@opensourcerouting.org> - %{version}
42 * Tue Nov 7 2017 Martin Winter <mwinter@opensourcerouting.org> - 7.2
44 - Add new entry to the top of the list with ``%{version}`` tag. Make sure
45 to watch the format, i.e. the day is always 2 characters, with the 1st
46 character being a space if the day is one digit.
48 - Add the changelog text below this entry.
50 5. Update Changelog for Debian Packages:
52 Edit :file:`changelog-auto.in`:
54 - Change last (top of list) entry from ``@VERSION@`` to the **last**
55 released version number. For example, if ``<version>`` is ``7.3`` and the
56 last public release was ``7.2``, you would use ``7.2``, changing the file
59 frr (@VERSION@) RELEASED; urgency=medium
63 frr (7.2) RELEASED; urgency=medium
65 - Add a new entry to the top of the list with a ``@VERSION@`` tag. Make sure
68 - Add the changelog text below this entry.
70 - Verify the changelog format using ``dpkg-parsechangelog``. In the
73 .. code-block:: console
77 You should see output like this::
79 vagrant@local ~/frr> dpkg-parsechangelog
82 Distribution: UNRELEASED
84 Maintainer: FRRouting-Dev <dev@lists.frrouting.org>
86 Date: Thu, 25 Oct 2018 16:36:50 +0200
88 frr (7.3-dev-0) RELEASED; urgency=medium
92 6. Change main version number:
94 - Edit :file:`configure.ac` and change version in the ``AC_INIT`` command
97 7. Commit the changes, adding the changelog to the commit message. Follow all
98 existing commit guidelines.
100 8. Create and submit a GitHub pull request, with the ``HEAD`` set to
101 ``stable/<version>`` and the base set to the upstream ``master`` branch.
102 Allow NetDef CI to complete its run and verify that all package builds were
105 9. Create a git tag for the version:
107 .. code-block:: console
109 git tag -a frr-<version> -m "FRRouting Release <version>"
111 10. Push the commit and new tag.
113 .. code-block:: console
115 git push origin stable/<version>:refs/head/stable/<version>
116 git push origin frr-<version>
118 11. Kick off the Release build plan on the CI system for the correct release.
119 Contact Martin Winter for this step. Ensure all release packages build
122 12. Kick off the Snapcraft build plan for the release.
124 13. Acquire the release RPM binary packages from Martin Winter.
126 14. On GitHub, go to the <https://github.com/FRRouting/frr/releases>_ and click
127 "Draft a new release". Write a release announcement. The release
128 announcement should follow the template in
129 ``release-announcement-template.md``, located next to this document. Check
130 for spelling errors, and optionally (but preferably) have other maintainers
131 proofread the announcement text.
133 Attach **only** the binary RPM packages to the GitHub release using
134 GitHub's attachment functionality. Do not attach Debian packages. Do not
135 attach source tarballs - these will be generated and attached by GitHub
136 automatically. Do not publish the release yet.
138 15. Contact the current Debian maintainer for FRR to get new Debian packages
139 built and published on our APT repository at https://deb.frrouting.net/.
140 Ensure the webpage text is updated. Verify that new packages install
141 successfully on a vanilla Debian installation using the instructions on the
144 16. Deploy Snapcraft release (after CI system finishes the tests for snapcraft
147 17. Update the Read The Docs instance to being publishing documentation built
148 off the ``stable/<version>`` branch. Contact Quentin Young for this step.
150 18. Publish the GitHub release.
152 19. Clone the ``frr-www`` repository:
154 .. code-block:: console
156 git clone https://github.com/FRRouting/frr-www.git
158 20. Add a new release announcement, using a previous announcement as template:
160 .. code-block:: console
162 cp <old-version>-launch.md <version>-launch.md
164 Paste the GitHub release announcement text into this document, and **remove
165 line breaks**. In other words, this::
167 This is one continuous
168 sentence that should be
171 Needs to be changed to this::
173 This is one continuous sentence that should be rendered on one line
175 This is very important otherwise the announcement will be unreadable on the
178 Make sure to add a link to the GitHub releases page at the top.
180 Once finished, manually add a new entry into ``index.html`` to link to this
181 new announcement. Look at past commits to see how to do this.
183 21. Deploy the updated ``frr-www`` on the frrouting.org web server and verify
184 that the announcement text is visible.
186 22. Send an email to ``announce@lists.frrouting.org``. The text of this email
187 should include the text from the GitHub release.
189 23. Update masters version of the changelog-auto.in
191 Take the change data and cut-n-paste the changes into the master version below
192 the @VERSION@-0 lines. So we have the history of the previous release.