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>