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