RELEASE-PROCEDURE.md (4618B)
1 <!-- 2 Copyright (C) Daniel Stenberg, <daniel@haxx.se>, et al. 3 4 SPDX-License-Identifier: curl 5 --> 6 7 curl release procedure - how to do a release 8 ============================================ 9 10 in the source code repo 11 ----------------------- 12 13 - edit `RELEASE-NOTES` to be accurate 14 15 - update `docs/THANKS` 16 17 - update the "past releases" section in `docs/VERSIONS.md` 18 19 - make sure all relevant changes are committed on the master branch 20 21 - tag the git repo in this style: `git tag -a curl-7_34_0`. -a annotates the 22 tag and we use underscores instead of dots in the version number. Make sure 23 the tag is GPG signed (using -s). 24 25 - run `./scripts/dmaketgz 7.34.0` to build the release tarballs. 26 27 - push the git commits and the new tag 28 29 - GPG sign the 4 tarballs as `maketgz` suggests 30 31 - upload the 8 resulting files to the primary download directory 32 33 in the curl-www repo 34 -------------------- 35 36 - edit `Makefile` (version number and date), 37 38 - edit `_newslog.html` (announce the new release) and 39 40 - edit `_changes.html` (insert changes+bugfixes from RELEASE-NOTES) 41 42 - commit all local changes 43 44 - tag the repo with the same name as used for the source repo. 45 46 - make sure all relevant changes are committed and pushed on the master branch 47 48 (the website then updates its contents automatically) 49 50 on GitHub 51 --------- 52 53 - edit the newly made release tag so that it is listed as the latest release 54 55 inform 56 ------ 57 58 - send an email to curl-users, curl-announce and curl-library. Insert the 59 RELEASE-NOTES into the mail. 60 61 - if there are any advisories associated with the release, send each markdown 62 file to the above lists as well as to `oss-security@lists.openwall.com` 63 (unless the problem is unique to the non-open operating systems) 64 65 celebrate 66 --------- 67 68 - suitable beverage intake is encouraged for the festivities 69 70 curl release scheduling 71 ======================= 72 73 Release Cycle 74 ------------- 75 76 We normally do releases every 8 weeks on Wednesdays. If important problems 77 arise, we can insert releases outside the schedule or we can move the release 78 date. 79 80 Each 8 week (56 days) release cycle is divided into three distinct periods: 81 82 - During the first 10 calendar days after a release, we are in "cool down". We 83 do not merge features but only bug-fixes. If a regression is reported, we 84 might do a follow-up patch release. 85 86 - During the following 3 weeks (21 days) there is a feature window: we allow 87 new features and changes to curl and libcurl. If we accept any such changes, 88 we bump the minor number used for the next release. 89 90 - During the next 25 days we are in feature freeze. We do not merge any 91 features or changes, and we only focus on fixing bugs and polishing things 92 to make the pending release a solid one. 93 94 If a future release date happens to end up on a "bad date", like in the middle 95 of common public holidays or when the lead release manager is unavailable, the 96 release date can be moved forwards or backwards a full week. This is then 97 advertised well in advance. 98 99 Release Candidates 100 ------------------ 101 102 We ship release candidate tarballs on three occasions in preparation for the 103 pending release: 104 105 - Release candidate one (**rc1**) ships the same Saturday the feature freeze 106 starts. Twenty-five days before the release. Tagged like `rc-7_34_0-1`. 107 108 - Release candidate two (**rc2**) ships nine days later, sixteen days before 109 the release. On a Monday. Tagged like `rc-7_34_0-2`. 110 111 - Release candidate tree (**rc3**) ships nine days later, seven days before 112 the release. On a Wednesday. Tagged like `rc-7_34_0-3`. 113 114 Release candidate tarballs are ephemeral and each such tarball is only kept 115 around for a few weeks. They are provided on their dedicated webpage at: 116 https://curl.se/rc/ 117 118 The git tags for release candidate are temporary and remain set only for a 119 limited period of time. 120 121 **Do not use release candidates in production**. They are work in progress. 122 Use them for testing and verification only. Use actual releases in production. 123 124 Critical problems 125 ----------------- 126 127 We can break the release cycle and do a patch release at any point if a 128 critical enough problem is reported. There is no exact definition of how to 129 assess such criticality, but if an issue is highly disturbing or has a 130 security impact on a large enough share of the user population it might 131 qualify. 132 133 If you think an issue qualifies, bring it to the curl-library mailing list and 134 push for it. 135 136 Coming dates 137 ------------ 138 139 Based on the description above, here are some planned future release dates: 140 141 - May 28, 2025 142 - July 16, 2025 143 - September 10, 2025 144 - November 5, 2025 145 - January 7, 2026 146 - March 4, 2026 147 - April 29, 2026