1<!-- 2Copyright (C) Daniel Stenberg, <daniel@haxx.se>, et al. 3 4SPDX-License-Identifier: curl 5--> 6 7curl release procedure - how to do a release 8============================================ 9 10in the source code repo 11----------------------- 12 13- do a *regular build* with a sensible build config to make sure the 14 `src/tool_hugehelp.c` file etc is correctly generated 15 16- edit `RELEASE-NOTES` to be accurate 17 18- update `docs/THANKS` 19 20- make sure all relevant changes are committed on the master branch 21 22- tag the git repo in this style: `git tag -a curl-7_34_0`. -a annotates the 23 tag and we use underscores instead of dots in the version number. Make sure 24 the tag is GPG signed (using -s). 25 26- run `./scripts/dmaketgz 7.34.0` to build the release tarballs. 27 28- push the git commits and the new tag 29 30- GPG sign the 4 tarballs as `maketgz` suggests 31 32- upload the 8 resulting files to the primary download directory 33 34in the curl-www repo 35-------------------- 36 37- edit `Makefile` (version number and date), 38 39- edit `_newslog.html` (announce the new release) and 40 41- edit `_changes.html` (insert changes+bugfixes from RELEASE-NOTES) 42 43- commit all local changes 44 45- tag the repo with the same name as used for the source repo. 46 47- make sure all relevant changes are committed and pushed on the master branch 48 49 (the website then updates its contents automatically) 50 51on GitHub 52--------- 53 54- edit the newly made release tag so that it is listed as the latest release 55 56inform 57------ 58 59- send an email to curl-users, curl-announce and curl-library. Insert the 60 RELEASE-NOTES into the mail. 61 62celebrate 63--------- 64 65- suitable beverage intake is encouraged for the festivities 66 67curl release scheduling 68======================= 69 70Release Cycle 71------------- 72 73We normally do releases every 8 weeks on Wednesdays. If important problems 74arise, we can insert releases outside the schedule or we can move the release 75date. 76 77Each 8 week (56 days) release cycle is divided into three distinct periods: 78 79- During the first 10 calendar days after a release, we are in "cool down". We 80 do not merge features but only bug-fixes. If a regression is reported, we 81 might do a follow-up patch release. 82 83- During the following 3 weeks (21 days) there is a feature window: we allow 84 new features and changes to curl and libcurl. If we accept any such changes, 85 we bump the minor number used for the next release. 86 87- During the next 25 days we are in feature freeze. We do not merge any 88 features or changes, and we only focus on fixing bugs and polishing things 89 to make the pending release a solid one. 90 91If a future release date happens to end up on a "bad date", like in the middle 92of common public holidays or when the lead release manager is unavailable, the 93release date can be moved forwards or backwards a full week. This is then 94advertised well in advance. 95 96Critical problems 97----------------- 98 99We can break the release cycle and do a patch release at any point if a 100critical enough problem is reported. There is no exact definition of how to 101assess such criticality, but if an issue is highly disturbing or has a 102security impact on a large enough share of the user population it might 103qualify. 104 105If you think an issue qualifies, bring it to the curl-library mailing list and 106push for it. 107 108Coming dates 109------------ 110 111Based on the description above, here are some planned release dates (at the 112time of this writing): 113 114- May 22, 2024 115- July 17, 2024 116- September 11, 2024 117- November 6, 2024 118- January 8, 2025 119- March 5, 2025 120- April 30, 2025 121- June 25, 2025 122