admin/PowerShell-PowerShell
1
0
Fork 0
mirror of https://github.com/PowerShell/PowerShell synced 2026-06-08 12:12:50 +00:00
Code Issues Packages Projects Releases Wiki Activity

Update releasing documentation

Browse Source
This commit is contained in:
Andrew Schwartzmeyer
2016-07-28 14:40:34 -07:00
parent 6e44b52c92
commit ba5bcbc8f3
1 changed files with 18 additions and 11 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/maintainers/releasing.md
+18 -11
View File
@@ -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.