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