From db73e72d8c31a34afbf7f93f8c9444b55511b477 Mon Sep 17 00:00:00 2001 From: Daniel Stenberg Date: Fri, 15 Jun 2018 13:37:48 +0200 Subject: docs/RELEASE-PROCEDURE.md: renamed to use .md extension --- docs/Makefile.am | 46 +++++++++++++++++++---- docs/RELEASE-PROCEDURE | 96 ----------------------------------------------- docs/RELEASE-PROCEDURE.md | 96 +++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 135 insertions(+), 103 deletions(-) delete mode 100644 docs/RELEASE-PROCEDURE create mode 100644 docs/RELEASE-PROCEDURE.md diff --git a/docs/Makefile.am b/docs/Makefile.am index bdd96fdd9..68ab5d45f 100644 --- a/docs/Makefile.am +++ b/docs/Makefile.am @@ -40,13 +40,45 @@ DIST_SUBDIRS = $(SUBDIRS) examples libcurl CLEANFILES = $(GENHTMLPAGES) $(PDFPAGES) $(MANDISTPAGES) curl.1 -EXTRA_DIST = MANUAL BUGS CONTRIBUTE.md FAQ FEATURES INTERNALS.md SSLCERTS.md \ - README.win32 RESOURCES TODO TheArtOfHttpScripting THANKS VERSIONS KNOWN_BUGS \ - BINDINGS.md HISTORY.md INSTALL INSTALL.md LICENSE-MIXING.md \ - README.netware MAIL-ETIQUETTE HTTP-COOKIES.md SECURITY-PROCESS.md RELEASE-PROCEDURE \ - SSL-PROBLEMS.md HTTP2.md ROADMAP.md CODE_OF_CONDUCT.md CODE_STYLE.md \ - CHECKSRC.md CMakeLists.txt README.md CIPHERS.md INSTALL.cmake README.cmake \ - $(noinst_man_MANS) HELP-US.md GOVERNANCE.md +EXTRA_DIST = \ + $(noinst_man_MANS) \ + BINDINGS.md \ + BUGS \ + CHECKSRC.md \ + CIPHERS.md \ + CMakeLists.txt \ + CODE_OF_CONDUCT.md \ + CODE_STYLE.md \ + CONTRIBUTE.md \ + FAQ \ + FEATURES \ + GOVERNANCE.md \ + HELP-US.md \ + HISTORY.md \ + HTTP-COOKIES.md \ + HTTP2.md \ + INSTALL \ + INSTALL.cmake \ + INSTALL.md \ + INTERNALS.md \ + KNOWN_BUGS \ + LICENSE-MIXING.md \ + MAIL-ETIQUETTE \ + MANUAL \ + README.cmake \ + README.md \ + README.netware \ + README.win32 \ + RELEASE-PROCEDURE.md \ + RESOURCES \ + ROADMAP.md \ + SECURITY-PROCESS.md \ + SSL-PROBLEMS.md \ + SSLCERTS.md \ + THANKS \ + TODO \ + TheArtOfHttpScripting \ + VERSIONS MAN2HTML= roffit $< >$@ diff --git a/docs/RELEASE-PROCEDURE b/docs/RELEASE-PROCEDURE deleted file mode 100644 index 637d0a70b..000000000 --- a/docs/RELEASE-PROCEDURE +++ /dev/null @@ -1,96 +0,0 @@ -curl release procedure - how to do a release -============================================ - -in the source code repo ------------------------ - -- edit `RELEASE-NOTES` to be accurate - -- update `docs/THANKS` - -- make sure all relevant changes are committed on the master branch - -- tag the git repo in this style: `git tag -a curl-7_34_0`. -a annotates the - tag and we use underscores instead of dots in the version number. Make sure - the tag is GPG signed (using -s). - -- run "./maketgz 7.34.0" to build the release tarballs. It is important that - you run this on a machine with the correct set of autotools etc installed - as this is what then will be shipped and used by most users on *nix like - systems. - -- push the git commits and the new tag - -- gpg sign the 4 tarballs as maketgz suggests - -- upload the 8 resulting files to the primary download directory - -in the curl-www repo --------------------- - -- edit `Makefile` (version number and date), - -- edit `_newslog.html` (announce the new release) and - -- edit `_changes.html` (insert changes+bugfixes from RELEASE-NOTES) - -- commit all local changes - -- tag the repo with the same name as used for the source repo. - -- make sure all relevant changes are committed and pushed on the master branch - - (the web site then updates its contents automatically) - -on github ---------- - -- edit the newly made release tag so that it is listed as the latest release - -inform ------- - -- send an email to curl-users, curl-announce and curl-library. Insert the - RELEASE-NOTES into the mail. - -celebrate ---------- - -- suitable beverage intake is encouraged for the festivities - -curl release scheduling -======================= - -Basics ------- - -We do releases every 8 weeks on Wednesdays. If critical problems arise, we can -insert releases outside of the schedule or we can move the release date - but -this is very rare. - -Each 8 week release cycle is split in two 4-week periods. - -- During the first 4 weeks after a release, we allow new features and changes - to curl and libcurl. If we accept any such changes, we bump the minor number - used for the next release. - -- During the second 4-week period we do not merge any features or changes, we - then only focus on fixing bugs and polishing things to make a solid coming - release. - -Coming dates ------------- - -Based on the description above, here are some planned release dates (at the -time of this writing): - -- July 11, 2018 -- September 5, 2018 -- October 31, 2018 -- December 26, 2018 -- February 20, 2019 -- April 17, 2019 -- June 12, 2019 -- August 7, 2019 -- October 2, 2019 -- December 27, 2019 diff --git a/docs/RELEASE-PROCEDURE.md b/docs/RELEASE-PROCEDURE.md new file mode 100644 index 000000000..637d0a70b --- /dev/null +++ b/docs/RELEASE-PROCEDURE.md @@ -0,0 +1,96 @@ +curl release procedure - how to do a release +============================================ + +in the source code repo +----------------------- + +- edit `RELEASE-NOTES` to be accurate + +- update `docs/THANKS` + +- make sure all relevant changes are committed on the master branch + +- tag the git repo in this style: `git tag -a curl-7_34_0`. -a annotates the + tag and we use underscores instead of dots in the version number. Make sure + the tag is GPG signed (using -s). + +- run "./maketgz 7.34.0" to build the release tarballs. It is important that + you run this on a machine with the correct set of autotools etc installed + as this is what then will be shipped and used by most users on *nix like + systems. + +- push the git commits and the new tag + +- gpg sign the 4 tarballs as maketgz suggests + +- upload the 8 resulting files to the primary download directory + +in the curl-www repo +-------------------- + +- edit `Makefile` (version number and date), + +- edit `_newslog.html` (announce the new release) and + +- edit `_changes.html` (insert changes+bugfixes from RELEASE-NOTES) + +- commit all local changes + +- tag the repo with the same name as used for the source repo. + +- make sure all relevant changes are committed and pushed on the master branch + + (the web site then updates its contents automatically) + +on github +--------- + +- edit the newly made release tag so that it is listed as the latest release + +inform +------ + +- send an email to curl-users, curl-announce and curl-library. Insert the + RELEASE-NOTES into the mail. + +celebrate +--------- + +- suitable beverage intake is encouraged for the festivities + +curl release scheduling +======================= + +Basics +------ + +We do releases every 8 weeks on Wednesdays. If critical problems arise, we can +insert releases outside of the schedule or we can move the release date - but +this is very rare. + +Each 8 week release cycle is split in two 4-week periods. + +- During the first 4 weeks after a release, we allow new features and changes + to curl and libcurl. If we accept any such changes, we bump the minor number + used for the next release. + +- During the second 4-week period we do not merge any features or changes, we + then only focus on fixing bugs and polishing things to make a solid coming + release. + +Coming dates +------------ + +Based on the description above, here are some planned release dates (at the +time of this writing): + +- July 11, 2018 +- September 5, 2018 +- October 31, 2018 +- December 26, 2018 +- February 20, 2019 +- April 17, 2019 +- June 12, 2019 +- August 7, 2019 +- October 2, 2019 +- December 27, 2019 -- cgit v1.2.1