<commit_before># Packaging for .NET Standard 2.0

This document outlines how packaging for .NET Standard 2.0 will work. This
covers package layout, versioning semantics, compatiblity with existing
packages, and how package consumption will work.

## Requirements

* **Simple**. In order to be understandable, we want the .NET Standard package
  graph to be extremely simple, ideally a single package.
* **Cumulative**. Upgrading this package should never result in changes of
  platform compatiblity or API surface.
* **Packages don't need to depend on the .NET Standard package**. This makes
  building packages that target .NET Standard similar to how it works for other
  .NET platforms (such as .NET Framework).
* **Independent from platform implementations**. The .NET Standard package
  shouldn't need to know about the platforms implementing the standard. This
  avoids having to update the .NET Standard package every time a platform is
  updated or added.
* **Compatible with .NET Standard 1.x**. The package for .NET Standard 2.0 needs
  to work with packages that were built against .NET Standard 1.x.

## Experience

Moving forward we plan on having two types of packages:

* **Platform packages**. These are monolithic packages that represent a given
  .NET platform. This includes .NET Core (`Microsoft.NETCore.App`) as well as
  .NET Standard (`NETStandard.Library`).

* **Library packages**. These are libraries that target .NET Standard and are
  thus shared components across all .NET platforms. This includes some `System`
  packages (such as `System.Collections.Immutable`) but also inlcudes all other
  libraries on NuGet (such as `Newtonsoft.Json`).

*Platform packages* will be referenced by projects but not by packages (except
for very specialized tooling packages). Instead, *library packages* will express
their dependency on the platform by the folder name convention that already
exists today, such as `lib/net45` and `lib/netstandard16`.

The version of the platform package represents the version of its
implementation, not the API surface. For example, it's possible to depend on the
latest version of a platform package and still target an earlier version. That's
because projects express them as separate pieces of configuration:

* The `<TargetFramework>` property (and also `<TargetFrameworks>` if you compile
  for multiple frameworks). This expresses which version of the API surface you
  can target.

* The `<PackageReference />` item. Expresses which version of the platform
  package you are using.

Since platform packages are cumulative, you can always upgrade to the latest
version and continue to target the current version. This is especially useful
for .NET Standard, as the API version controls on which platforms you can run.
<commit_msg>Fix typo of includes in packaging docs<commit_after># Packaging for .NET Standard 2.0

This document outlines how packaging for .NET Standard 2.0 will work. This
covers package layout, versioning semantics, compatiblity with existing
packages, and how package consumption will work.

## Requirements

* **Simple**. In order to be understandable, we want the .NET Standard package
  graph to be extremely simple, ideally a single package.
* **Cumulative**. Upgrading this package should never result in changes of
  platform compatiblity or API surface.
* **Packages don't need to depend on the .NET Standard package**. This makes
  building packages that target .NET Standard similar to how it works for other
  .NET platforms (such as .NET Framework).
* **Independent from platform implementations**. The .NET Standard package
  shouldn't need to know about the platforms implementing the standard. This
  avoids having to update the .NET Standard package every time a platform is
  updated or added.
* **Compatible with .NET Standard 1.x**. The package for .NET Standard 2.0 needs
  to work with packages that were built against .NET Standard 1.x.

## Experience

Moving forward we plan on having two types of packages:

* **Platform packages**. These are monolithic packages that represent a given
  .NET platform. This includes .NET Core (`Microsoft.NETCore.App`) as well as
  .NET Standard (`NETStandard.Library`).

* **Library packages**. These are libraries that target .NET Standard and are
  thus shared components across all .NET platforms. This includes some `System`
  packages (such as `System.Collections.Immutable`) but also includes all other
  libraries on NuGet (such as `Newtonsoft.Json`).

*Platform packages* will be referenced by projects but not by packages (except
for very specialized tooling packages). Instead, *library packages* will express
their dependency on the platform by the folder name convention that already
exists today, such as `lib/net45` and `lib/netstandard16`.

The version of the platform package represents the version of its
implementation, not the API surface. For example, it's possible to depend on the
latest version of a platform package and still target an earlier version. That's
because projects express them as separate pieces of configuration:

* The `<TargetFramework>` property (and also `<TargetFrameworks>` if you compile
  for multiple frameworks). This expresses which version of the API surface you
  can target.

* The `<PackageReference />` item. Expresses which version of the platform
  package you are using.

Since platform packages are cumulative, you can always upgrade to the latest
version and continue to target the current version. This is especially useful
for .NET Standard, as the API version controls on which platforms you can run.

{'fraction_non_alphanumeric': 0.05963220853419032, 'fraction_numerical': 0.004284949116229245, 'mean_word_length': 4.47605083088954, 'pattern_counts': {'":': 0, '<': 9, '<?xml version=': 0, '>': 9, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '1188383', 'n_tokens_mistral': 1365, 'n_tokens_neox': 1299, 'n_words': 788}