path: root/Documentation
diff options
authorJan Kotas <>2019-06-26 23:47:04 (GMT)
committerGitHub <>2019-06-26 23:47:04 (GMT)
commit1a8f735d4f397424349f1de0017314f16296f638 (patch)
tree5caf4e6fc4150417aa96407c5b04d42f11b6a21e /Documentation
parent18168f63efda22f7a9e6f1d0e49c3a5604fe8f6c (diff)
Update docs (#25446)
- Delete references to Jenkins CI - Add note on Squash&Merge
Diffstat (limited to 'Documentation')
3 files changed, 12 insertions, 153 deletions
diff --git a/Documentation/building/ b/Documentation/building/
index eb4f325..7b7cc66 100644
--- a/Documentation/building/
+++ b/Documentation/building/
@@ -30,46 +30,6 @@ During development there are many instances where building an individual test is
>`/path/to/coreclr/.dotnet/dotnet msbuild tests/src/path-to-proj-file /p:__BuildOS=<BuildOS> /p:__BuildType=<BuildType>`
-## Aarch64/armhf multi-arch
-For machines that have aarch64/armhf support, all the armhf packages will need to also be downloaded. Please note you will need to enable multiplatform support as well. Check with your distro provider or kernel options to see if this is supported. For simplicity, these instructions relate to aarch64 ubuntu enabling arm32 (hf) coreclr runs.
-Please make sure your device is running a 64-bit aarch64 kernel.
-# Example output
-[ubuntu:~]: uname -a
-Linux tegra-ubuntu 4.4.38-tegra #1 SMP PREEMPT Thu Jul 20 00:41:06 PDT 2017 aarch64 aarch64 aarch64 GNU/Linux
-# Enable armhf multiplatform support
-[ubuntu:~]: sudo dpkg --add-architecture armhf
-[ubuntu:~]: sudo apt-get update
-[ubuntu:~]: sudo apt-get install libstdc++6:armhf
-At this point, you should be able to run a 32-bit `corerun`. You can verify this by downloading and running a recently built arm32 coreclr.
-[ubuntu:~]: wget*zip*/ --no-check-certificate
-[ubuntu:~]: unzip
-[ubuntu:~]: chmod +x && ./archive/bin/Product/Linux.arm.Checked/corerun
-Execute the specified managed assembly with the passed in arguments
--c, --clr-path path to the and the managed CLR assemblies
-Now download the coreclr armhf dependencies.
-sudo apt-get install libunwind8:armhf libunwind8-dev:armhf libicu-dev:armhf liblttng-ust-dev:armhf libcurl4-openssl-dev:armhf libicu-dev:armhf libssl-dev libkrb5-dev:armhf
## Running Tests
The following instructions assume that on the Unix machine:
diff --git a/Documentation/project-docs/ b/Documentation/project-docs/
index 20ce15f..f92f8a2 100644
--- a/Documentation/project-docs/
+++ b/Documentation/project-docs/
@@ -33,7 +33,7 @@ Note: It is OK to create your PR as "[WIP]" on the upstream repo before the impl
## PR - CI Process
-The [dotnet continuous integration]( (CI) system will automatically perform the required builds and run tests (including the ones you are expected to run) for PRs. Builds and test runs must be clean.
+The [dotnet continuous integration]( (CI) system will automatically perform the required builds and run tests (including the ones you are expected to run) for PRs. Builds and test runs must be clean.
If the CI build fails for any reason, the PR issue will be updated with a link that can be used to determine the cause of the failure.
@@ -44,3 +44,14 @@ Microsoft team and community members will provide feedback on your change. Commu
1 or more Microsoft team members will review every PR prior to merge. They will often reply with "LGTM, modulo comments". That means that the PR will be merged once the feedback is resolved. "LGTM" == "looks good to me".
There are lots of thoughts and [approaches]( for how to efficiently discuss changes. It is best to be clear and explicit with your feedback. Please be patient with people who might not understand the finer details about your approach to feedback.
+# Merging Pull Requests (for contributors with write access)
+Use ["Squash and Merge"]( by default for individual contributions unless requested by the PR author.
+ Do so, even if the PR contains only one commit. It creates a simpler history than "Create a Merge Commit".
+ Reasons that PR authors may request "Merge and Commit" may include (but are not limited to):
+ - The change is easier to understand as a series of focused commits. Each commit in the series must be buildable so as not to break `git bisect`.
+ - Contributor is using an e-mail address other than the primary GitHub address and wants that preserved in the history. Contributor must be willing to squash
+ the commits manually before acceptance.
diff --git a/Documentation/workflow/ b/Documentation/workflow/
deleted file mode 100644
index 083df3e..0000000
--- a/Documentation/workflow/
+++ /dev/null
@@ -1,112 +0,0 @@
-# Official Releases and Daily Builds of CoreCLR and CoreFX components
-If you are not planning on actually making bug fixes or experimenting with new features, then you probably
-don't need to build CoreCLR yourself, as the .NET Runtime team routinely does this for you.
-Roughly every three months, the .NET Runtime team publishes a new version of .NET Core to Nuget. .NET Core's
-official home on NuGet is
- * <>
-and you can expect to see new versions roughly three months. However it is also the case that the .NET
-Team publishes **daily builds** of all sorts of packages including those built by the CoreCLR and CoreFX
-repositories. You can see what is available from
- * <>, and in particular you can see the builds of
- * CoreCLR at <>
- * NETCore.App at <>
-These builds have a version number that follows the the versioning scheme described below (month number/day of month),
-but they also will have a component that indicate which Git Branch the are working from (note these names were
-correct as of 1/2018 and may change but the concept of a suffix that designates the branch is likely to persist)
- * preview1 - are daily builds from the 'release/\*' branch where \* is the next official version to be released
- * preview2 - are daily builds from the 'master' branch (where active work happens first (typically))
-Thus if your goal is just to get the latest bug fixes and features, you don't need to build CoreCLR yourself you
-can simply add <> to your Nuget Feed list and set the
-`RuntimeFrameworkVersion` in your project file to a `Microsoft.NETCore.App` version. You need to restore
-and publish your application so it includes the runtime (`self-contained`). This is done by setting the
-`RuntimeIdentifier` (e.g. `linux-x64`, `win7-x64`).
-<?xml version="1.0" encoding="utf-8"?>
- <packageSources>
- <add key="dotnet-core" value=""/>
- </packageSources>
-<Project Sdk="Microsoft.NET.Sdk">
- <PropertyGroup>
- <OutputType>Exe</OutputType>
- <TargetFramework>netcoreapp2.0</TargetFramework>
- <RuntimeFrameworkVersion>2.0.0-preview2-*</RuntimeFrameworkVersion>
- <RuntimeIdentifier>linux-x64</RuntimeIdentifier>
- </PropertyGroup>
-$ dotnet restore
-$ dotnet publish
-$ dotnet bin/Debug/netcoreapp2.0/linux-x64/publish/<app>.dll
-## Package Version Numbers
-Version numbers for Nuget packages look like the following
- 1.0.24214.01
-Which have the form
- <major>.<minor>.<buildNumberMajor>.<buildNumberMinor>
-* The major version number represents a compatibility band. If the next release of the package is not
- backward compatible (most apps that run on version N-1 will run on version N) then this number is increased.
- This number is not likely to change (we care about compatibility alot)
-* The minor number is increased every time interesting new features are added (not just minor bug fixes).
- For CoreCLR we tend to update this every time we create a public release (every 3 months).
-* The Major Build Number is a number that represents a daily build. The last 2 digits of this build number
- is the **day of the month** of the GIT commit that is being built. Thus we know in the example above this
- build's last commit to GIT happened on the 14th day of the month. The most significant digits represents
- the month count since April 1996. In the example above 242 represents Jun 2016.
-* The Minor Build number is something that disambiguates different builds that share the same
- commit (or the different commits on the same day). It is a sequential number and is typically 1 for
- official builds, and 0 for developer builds. (You can set the environment variable BuildNumberMinor if
- you wish to set it for your own builds).
-See the [Package and File Versioning]( page
-for more details on how the build version number is generated.
-# Build/Test Status of the repository
-As mentioned we build the CoreCLR repository daily, and as part of that build we also run all
-the tests associted with this repository. Below is a table of the most recent results for all
-the different operating systems and architectures that we routinely build.
-If you click on the images below, you can get more details about the build (including the binaries)
-and the exact test results (in case your build is failing tests and you are wondering if it is
-something affecting all builds).
-| | X64 Debug | X64 Release | ARM64 Debug | ARM64 Release |
-|**CentOS 7.1**|[![x64 status](](|[![x64 status](](|||
-|**Debian 8.4**|[![x64 status](](|[![x64 status](](|||
-|**FreeBSD 10.1**|[![x64 status](](|[![x64 status](](|||
-|**openSUSE 42.1**|[![x64 status](](|[![x64 status](](|||
-|**OS X 10.12**|[![x64 status](](|[![x64 status](](|||
-|**Red Hat 7.2**|[![x64 status](](|[![x64 status](](|||
-|**Ubuntu 14.04**|[![x64 status](](|[![x64 status](](|||
-|**Ubuntu 16.04**|[![x64 status](](|[![x64 status](](|||
-|**Ubuntu 16.10**|[![x64 status](](|[![x64 status](](|||
-|**Windows 8.1**|[![x64 status](](|[![x64 status](](|[![arm64 status](](|[![arm64 status](](|