From 3e12a5f67f98c23cd5d28c1fe47ebfc53459ce87 Mon Sep 17 00:00:00 2001 From: ctrlaltca Date: Fri, 21 Apr 2017 14:26:55 +0200 Subject: [PATCH] Update CONTRIBUTING.md (#2613) * Update CONTRIBUTING.md * Update CONTRIBUTING.md "wait for CI upload" should be "wait for CI to upload" "update again the version number" should be "update the version number again" --- .github/CONTRIBUTING.md | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/.github/CONTRIBUTING.md b/.github/CONTRIBUTING.md index 41975345..405bac5a 100644 --- a/.github/CONTRIBUTING.md +++ b/.github/CONTRIBUTING.md @@ -249,3 +249,10 @@ git tag -d $TAG_NAME ``` **NOTE:** Unfortunately, due to the method of how TravisCI and Appveyor work, to publish a full release you will need to make a copy of the release notes locally and then paste them into the GitHub GUI once the binaries have been uploaded. These build sites will automatically change the name of the release (to $TAG_NAME from whatever it was), the status of the release (to pre-release), and the body (to "Dev build of Cockatrice"). + +**NOTE 2:** In the first lines of https://github.com/Cockatrice/Cockatrice/blob/master/CMakeLists.txt there's an hardcoded version number used when compiling custom (not tagged) versions. While on tagged versions these numbers are overriden by the version numbers coming from the tag title, it's a good practice to keep them aligned with the real ones. +The preferred flow of operations is: + * just before a release, update the version number in CMakeLists.txt to "next release version"; + * tag the release following the previously described syntax in order to get it built by CI; + * wait for CI to upload the binaries, double check if everything is in order + * after the release is complete, update the version number again to "next development version", typically increasing `PROJECT_VERSION_PATCH` by one.