xref: /curl/docs/RELEASE-PROCEDURE.md (revision 995db174)
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
59celebrate
60---------
61
62- suitable beverage intake is encouraged for the festivities
63
64curl release scheduling
65=======================
66
67Release Cycle
68-------------
69
70We normally do releases every 8 weeks on Wednesdays. If important problems
71arise, we can insert releases outside the schedule or we can move the release
72date.
73
74Each 8 week (56 days) release cycle is divided into three distinct periods:
75
76- During the first 10 calendar days after a release, we are in "cool down". We
77  do not merge features but only bug-fixes. If a regression is reported, we
78  might do a follow-up patch release.
79
80- During the following 3 weeks (21 days) there is a feature window: we allow
81  new features and changes to curl and libcurl. If we accept any such changes,
82  we bump the minor number used for the next release.
83
84- During the next 25 days we are in feature freeze. We do not merge any
85  features or changes, and we only focus on fixing bugs and polishing things
86  to make the pending release a solid one.
87
88If a future release date happens to end up on a "bad date", like in the middle
89of common public holidays or when the lead release manager is unavailable, the
90release date can be moved forwards or backwards a full week. This is then
91advertised well in advance.
92
93Critical problems
94-----------------
95
96We can break the release cycle and do a patch release at any point if a
97critical enough problem is reported. There is no exact definition of how to
98assess such criticality, but if an issue is highly disturbing or has a
99security impact on a large enough share of the user population it might
100qualify.
101
102If you think an issue qualifies, bring it to the curl-library mailing list and
103push for it.
104
105Coming dates
106------------
107
108Based on the description above, here are some planned future release dates:
109
110- December 11, 2024
111- February 5, 2025
112- April 2, 2025
113- May 28, 2025
114- July 23, 2025
115- September 17, 2025
116- November 12, 2025
117