Annotation of embedaddon/curl/docs/RELEASE-PROCEDURE.md, revision 1.1.1.1
1.1 misho 1: curl release procedure - how to do a release
2: ============================================
3:
4: in 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:
30: in 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 web site then updates its contents automatically)
46:
47: on github
48: ---------
49:
50: - edit the newly made release tag so that it is listed as the latest release
51:
52: inform
53: ------
54:
55: - send an email to curl-users, curl-announce and curl-library. Insert the
56: RELEASE-NOTES into the mail.
57:
58: celebrate
59: ---------
60:
61: - suitable beverage intake is encouraged for the festivities
62:
63: curl release scheduling
64: =======================
65:
66: Release Cycle
67: -------------
68:
69: We do releases every 8 weeks on Wednesdays. If critical problems arise, we can
70: insert releases outside of the schedule or we can move the release date - but
71: this is rare.
72:
73: Each 8 week release cycle is split in two 4-week periods.
74:
75: - During the first 4 weeks after a release, we allow new features and changes
76: to curl and libcurl. If we accept any such changes, we bump the minor number
77: used for the next release.
78:
79: - During the second 4-week period we do not merge any features or changes, we
80: then only focus on fixing bugs and polishing things to make a solid coming
81: release.
82:
83: - After a regular procedure-following release (made on Wednesdays), the
84: feature window remains closed until the following Monday in case of special
85: actions or patch releases etc.
86:
87: If a future release date happens to end up on a "bad date", like in the middle
88: of common public holidays or when the lead release manager is away traveling,
89: the release date can be moved forwards or backwards a full week. This is then
90: advertised well in advance.
91:
92: Coming dates
93: ------------
94:
95: Based on the description above, here are some planned release dates (at the
96: time of this writing):
97:
98: - March 4, 2020 (7.69.0)
99: - April 29, 2020
100: - June 24, 2020
101: - August 19, 2020
102: - October 14, 2020
103: - December 9, 2020
104: - February 3, 2021
105:
106: The above (and more) curl-related dates are published in
107: [iCalendar format](https://calendar.google.com/calendar/ical/c9u5d64odop9js55oltfarjk6g%40group.calendar.google.com/public/basic.ics)
108: as well.
FreeBSD-CVSweb <freebsd-cvsweb@FreeBSD.org>