mirrors/PowerShell
0
0
Fork 0
mirror of https://github.com/PowerShell/PowerShell.git synced 2024-11-27 20:05:34 +08:00
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #1401 from alexandair/patch-4

Browse Source 
Update README.md
This commit is contained in:
Sergei Vorobev 2016-07-20 15:46:37 -07:00 committed by GitHub
commit 32c8fd659c
1 changed files with 33 additions and 37 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

70
docs/releasing/README.md
View File

@ -1,22 +1,22 @@
Preparing
=========
Open 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.
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.
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`. 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.3.0 alpha release of Open PowerShell'.
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`.
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'.
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.
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.
[semver]: http://semver.org/
[tag]: https://git-scm.com/book/en/v2/Git-Basics-Tagging
@ -28,39 +28,35 @@ Building Packages
Linux / OS X
------------
The `build.psm1` module contains a `Start-PSPackage` function to build Linux
packages. It requires that `Start-PSBuild -Publish` has been run. 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.
The `build.psm1` module contains a `Start-PSPackage` function to build Linux packages.
It requires that `Start-PSBuild -Publish` has been run.
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`.
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, which makes building packages for any (non-Windows) platform a breeze.
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.
To modify any property of the packages, edit the `Start-PSPackage` function.
Please also refer to the function for details on the package properties (such as
the description, maintainer, vendor, URL, license, category, dependencies, and
file layout).
Please also refer to the function for details on the package properties (such as the description,
maintainer, vendor, URL, license, category, dependencies, and file layout).
[fpm]: https://github.com/jordansissel/fpm
Windows
-------
The `Start-PSBuild` function delegates to `New-MSIPackage` which creates a
Windows Installer Package of Open PowerShell. It uses the Windows Installer XML
Toolset (WiX) to generate a `OpenPowerShell_<version>.msi`, which installs a
self-contained copy of the current version (commit) of Open PowerShell. It
copies the output of the published PowerShell application to a version-specific
folder in Program Files, and installs a shortcut in the start-menu. It can be
uninstalled through Programs and Features.
The `Start-PSBuild` function delegates to `New-MSIPackage` which creates a Windows Installer Package of PowerShell.
It uses the Windows Installer XML Toolset (WiX) to generate a `PowerShell_<version>.msi`,
which installs a self-contained copy of the current version (commit) of PowerShell.
It copies the output of the published PowerShell application to a version-specific folder in Program Files,
and installs a shortcut in the Start Menu.
It can be uninstalled through Programs and Features.
Note that Open PowerShell is always self-contained, thus using it does not
require installing it. The output of `Start-PSBuild -Publish` includes a
`powershell.exe` executable which can simply be launched.
Note that PowerShell is always self-contained, thus using it does not require installing it.
The output of `Start-PSBuild -Publish` includes a `powershell.exe` executable which can simply be launched.