1=============== 2Release process 3=============== 4 5The document describes the technical aspect of making a flashrom release, 6and it assumes that the team of active core maintainers is in agreement to commence the process. 7 8To go through the process, at least two maintainers are needed to be closely involved, 9because it includes sending and approving patches in Gerrit. 10 11Set up the timeline and announce on the mailing list 12==================================================== 13 14Decide on the bug-fixing and testing window (3-4 weeks), decide exact dates of start and end of the window, 15and announce it on the mailing list. Ideally make an announcement a few weeks in advance. 16 17During the testing and bug-fixing window only bug fixes are merged, and no new features are added. 18Typically it's fine to push new features for review, and reviews are fine too, 19but merging new features will be delayed until the release is done. 20*This should be very clearly explained in the announcement.* 21 22Start testing and bug-fixing window 23=================================== 24 25* Double-check and merge all the patches that are fully ready (see also :ref:`merge-checklist`) 26 27* Update VERSION file to first release candidate. The name pattern is: ``v{version_number}-rc{rc_number}``. 28 29 * As an example, the version name of the first release candidate can be ``v1.4.0-rc1``. 30 * To update the VERSION file, push a patch to Gerrit, and another maintainer should review and approve. 31 32* After submitting the change to the VERSION file, tag this commit. Tag name should be the same as 33 version name, for example above ``v1.4.0-rc1``. 34 35* Write an announcement on the mailing list. Be very clear about: 36 37 * start and end date of the window, and what does it mean 38 * any help with :ref:`building-and-testing` is very much appreciated 39 40**From this moment and until the release cut, the highest priority is for building and testing on various environments, and bug-fixing.** 41 42Release candidates 43================== 44 45If any bugs are found and fixed (or reverted), then the second, or third release candidate will be needed. 46The process is the same as with the first candidate: 47 48* Update the VERSION file, and submit this 49* Tag the commit which updates the VERSION file 50* Post an announcement on mailing list 51 52Release notes 53============= 54 55During the time in-between releases, ideally most updates are accumulated in the doc :doc:`/release_notes/devel`. 56While this doc is helpful, it is not a replacement for a human to go through all development history 57since the previous release and prepare release notes. One maintainer is preparing the release notes 58and sending them for review, and at least one other maintainer needs to review that (it can be more than one reviewer). 59 60Ideally the patch with release notes should be prepared, reviewed and approved before the release cut, 61so that it can be published by the time of final release announcement. 62 63For inspiration to write release notes, have a look at prior art :doc:`/release_notes/index`. 64 65There is one section in release notes, Download, which is not possible to complete before the actual release cut. 66Leave it as TODO, but complete the rest. 67 68Cut the release 69=============== 70 71Wait for at least a week (or two) since the last release candidate. if everything is alright: 72 73* Submit the release notes, and in the same patch restart :doc:`/release_notes/devel` document. 74 This way everyone who is syncing the repository by the release tag will have release notes in the tree. 75 76* Update VERSION file to release version, name pattern is: ``v{version_name}`` 77 (for example, it can be ``v1.4.0``), and submit this. 78 79* Tag the commit which updates the VERSION file. Tag name should be the same as version name, 80 for example above ``v1.4.0``. 81 82* Create the tarball: 83 84 * At the moment of writing, the command we use ``meson dist --include-subprojects``, 85 more details are in `meson docs <https://mesonbuild.com/Creating-releases.html#creating-releases>`_. 86 * Check that tarball name follows the pattern ``flashrom-v{version_name}.tar.xz``, for example ``flashrom-v1.4.0.tar.xz``. 87 88* Sign the tarball, and upload to the server together with the signature. 89 90* Update release notes with the link to download tarball, signature, and fingerprint. Submit this and check that final release notes are published on the website. 91 92* Write the release announcement, don't forget to: 93 94 * Link to download the tarball, signature and fingerprint. 95 * Say thank you to everyone who is helping and supporting flashrom 96 * Add link to published release notes on the website 97 98Start the next cycle of development 99=================================== 100 101* Update the VERSION file to the development version. For example, the name pattern is: ``v{version_name}-devel``, 102 for example ``v1.5.0-devel``, and submit this. 103 104* Submit all the patches that have been ready and waiting. 105 106* Celebrate :) 107