From ba5bcbc8f370bd108388d72e51fbc07394de0640 Mon Sep 17 00:00:00 2001 From: Andrew Schwartzmeyer Date: Wed, 27 Jul 2016 17:57:34 -0700 Subject: [PATCH] Update releasing documentation --- docs/maintainers/releasing.md | 29 ++++++++++++++++++----------- 1 file changed, 18 insertions(+), 11 deletions(-) diff --git a/docs/maintainers/releasing.md b/docs/maintainers/releasing.md index 53bee6eeed..710434b607 100644 --- a/docs/maintainers/releasing.md +++ b/docs/maintainers/releasing.md @@ -2,22 +2,32 @@ Preparing ========= PowerShell releases use [Semantic Versioning][semver]. -Until we hit 1.0, each sprint results in a bump to the minor version number, -and interim bugfix releases bump the patch number. +Until we hit 6.0, each sprint results in a bump to the build number, +so `v6.0.0-alpha.7` goes to `v6.0.0-alpha.8`. -When a particular commit is chosen as a release, we create an [annotated tag][tag] that names the release, +When a particular commit is chosen as a release, +we create an [annotated tag][tag] that names the release, and list the major changes since the previous release. -An annotated tag has a message (like a commit), and is *not* the same as a lightweight tag. -Create one with `git tag -a vX.Y.Z`. +An annotated tag has a message (like a commit), +and is *not* the same as a lightweight tag. +Create one with `git tag -a v6.0.0-alpha.7`. Our convention is to prepend the `v` to the semantic version. The summary (first line) of the annotated tag message should be the full release title, -e.g. 'v0.6.0 beta release of Open PowerShell'. +e.g. 'v6.0.0-alpha.7 release of PowerShell'. When the annotated tag is finalized, push it with `git push --tags`. GitHub will see the tag and present it as an option when creating a new [release][]. Start the release, use the annotated tag's summary as the title, and save the release as a draft while you upload the binary packages. +Just as important as creating the release is updating the links on our readme, +and the package names in the installation instructions. +The AppVeyor build number should also be incremented. + +While it is not a big concern for developer previews, +the official releases should be created on dedicated machines +such that the debug symbols do not contain personal machine paths. + [semver]: http://semver.org/ [tag]: https://git-scm.com/book/en/v2/Git-Basics-Tagging [release]: https://help.github.com/articles/creating-releases/ @@ -34,11 +44,8 @@ The output *must* be published so that it includes the runtime. This function will automatically deduce the correct version from the most recent annotated tag (using `git describe`), and if not specified, will build a package for the current platform. -At this time, Linux packages must be built on Linux, and OS X packages on OS X; -however, an RPM can be created on Ubuntu. -This requires installing the `rpm` package, building with `-Runtime centos.7.1-x64`, and packaging with `-Type rpm`. - -The `Start-PSBuild` function relies on the [Effing Package Management][fpm] project, +At this time, each package must be made on the corresponding platform. +The `Start-PSBuild` function relies on the [Effing Package Management][fpm] project, which makes building packages for any (non-Windows) platform a breeze. Follow their readme to install FPM.