@@ -59,7 +59,7 @@ You can update message of local commits you haven't pushed yet using git commit
# Pull request
Start a GitHub pull request to merge your topic branch into the [main repository's master branch](https://github.com/Microsoft/WindowsDevicePortalWrapper/tree/master).
Start a GitHub pull request to merge your topic branch into the [main repository's **Development** branch](https://github.com/Microsoft/WindowsDevicePortalWrapper/tree/Development).
(If you are a Microsoft employee and are not a member of the [Microsoft organization on GitHub](https://github.com/Microsoft) yet, please contact the DDE team via e-mail for instructions before starting your pull request. There's some process stuff you'll need to do ahead of time.)
If you haven't contributed to a Microsoft project before, you may be asked to sign a [contribution license agreement](https://cla.microsoft.com/).
A comment in the PR will let you know if you do.
@@ -77,12 +77,11 @@ If the pull request review goes well, a project maintainer will merge your chang
When creating a new NuGet and GitHub release, the following steps should be taken:
1. Bump the version number as appropriate in master (after 1.0, WDP Wrapper will correctly use semver)
2. Merge from Master to Release, with a PR appropriately named ("v1.2.3 release")
3. Squash and merge commits, leaving major feature entries and fixes in the description.
4. Compile release builds of the .NET and UWP libraries, sign them, and upload to NuGet
2. Follow the steps documented in [Release Process](ReleaseProcess.md).
3. Compile release builds of the .NET and UWP libraries, sign them, and upload to NuGet
a. We now have a CI server for this that builds, signs, and packages the NuGet package [here](https://microsoft.visualstudio.com/DefaultCollection/OS/_build/index?path=%5C&definitionId=14239).
5. Cut a new release on GitHub using the same version number ("v1.2.3") and attach the signed libraries to the release.
6. Update code documentation.
4. Cut a new release on GitHub using the same version number ("v1.2.3") and attach the signed libraries to the release.
@@ -8,12 +8,16 @@ This project has adopted the [Microsoft Open Source Code of Conduct](https://ope
---
---
To start contributing, see [Contributing](https://github.com/Microsoft/WindowsDevicePortalWrapper/blob/master/CONTRIBUTING.md)
To start contributing, see [Contributing](https://github.com/Microsoft/WindowsDevicePortalWrapper/blob/master/CONTRIBUTING.md).
```
Note: The contribution guidelines were updated in January 2018 to have all pull requests go through the [**Development** branch](https://github.com/Microsoft/WindowsDevicePortalWrapper/tree/Development). Pull requests that target the master branch will be asked to be retargeted to the Development branch prior to approval.
```
---
---
For source code documentation, see https://microsoft.github.io/WindowsDevicePortalWrapper/annotated.html
For source code documentation, see https://microsoft.github.io/WindowsDevicePortalWrapper/annotated.html.
# The Windows Device Portal Wrapper Release Process
The following description and diagram illustrate the process that the Windows Device Portal Wrapper repository undergoes to create a release.
## Release Steps
0. [Performed one time on the repository] Create a Development branch off of master.
1. Declare that a release is feature complete.
This will done by / in coordination with the Windows Device Portal Wrapper maintainers.
2. Create a stabilization branch (ex: Stabilization_v1.2.3) off of Development
Bug fixes get submitted to the stabilization branch while work on the next release continues in Development. Note: While not expected in every release, there _may_ be some cherry-picking of individual commits from Development.
3. When the release has stabilized, a pull request is issued from the stabilization branch to master and it is merged.
The pull request should be squashed as part of the merge, with relevant feature and fix comments retained.
During this time, the release is compiled, signed, packaged and submitted to NuGet.
4. The master branch is tagged with the release's version number.
5. A pull request is issued from the master branch into development and it is merged.
No squashing is necessary on this merge.
6. The stabilization branch is, optionally, deleted.
The following diagram illustrates the process as it occurs across the repository branches.
