Public main to live

docs/concepts/Dependency-Resolution.md

@@ -63,6 +63,7 @@ When using a floating version, NuGet resolves the highest version of a package t
 | 1.1.* | 1.1.0 <br> 1.1.1 <br> 1.1.2-alpha <br> 1.2.0-alpha | 1.1.1 | The highest stable version that respects the specified pattern.|
 | \*-\* | 1.1.0 <br> 1.1.1 <br> 1.1.2-alpha <br> 1.3.0-beta  | 1.3.0-beta | The highest version including the not stable versions. | Available in Visual Studio version 16.6, NuGet version 5.6, .NET Core SDK version 3.1.300 |
 | 1.1.\*-\* | 1.1.0 <br> 1.1.1 <br> 1.1.2-alpha <br> 1.1.2-beta <br> 1.3.0-beta  | 1.1.2-beta | The highest version respecting the pattern and including the not stable versions. | Available in Visual Studio version 16.6, NuGet version 5.6, .NET Core SDK version 3.1.300 |
+| 1.2.0-rc.* | 1.1.0 <br> 1.2.0-rc.1 <br> 1.2.0-rc.2 <br> 1.2.0 | 1.2.0 | Despite this being a version range with a prerelease part, stables are allowed if they match the stable part. Given that 1.2.0 > 1.2.0-rc.2, it is chosen. |  |
 
 > [!Note]
 > Floating version resolution does not take into account whether or not a package is listed.

docs/consume-packages/Central-Package-Management.md

@@ -38,6 +38,11 @@ Central package management applies to all `<PackageReference>`-based MSBuild pro
 To get started with central package management, you must create a `Directory.Packages.props` file at the root of your repository and set the MSBuild property
 `ManagePackageVersionsCentrally` to `true`.
 
+You can create it manually or you can use the dotnet CLI:
+``` shell
+dotnet new packagesprops
+```
+
 Inside, you then define each of the respective package versions required of your projects using `<PackageVersion />` elements that define the package ID and
 version.
 
@@ -117,6 +122,7 @@ For an idea of how central package management may look like, refer to our [sampl
 
 You can automatically override a transitive package version even without an explicit top-level `<PackageReference />` by opting into a feature known as
 transitive pinning. This promotes a transitive dependency to a top-level dependency implicitly on your behalf when necessary.
+Note that downgrades are allowed when transitive pinning a package. If you attempt to pin a package to a lower version than the one requested by your dependencies, restore will raise a [NU1109](../reference/errors-and-warnings/NU1109.md) error.
 
 You can enable this feature by setting the MSBuild property `CentralPackageTransitivePinningEnabled` to `true` in a project or in a `Directory.Packages.props`
 or `Directory.Build.props` import file:
@@ -127,6 +133,45 @@ or `Directory.Build.props` import file:
 </PropertyGroup>
 ```
 
+### Transitive pinning and pack
+
+When a package is transitively pinned, your project uses a higher than the one requested by your dependencies.
+If you create a package from your project, in order to ensure that your package will work, NuGet will promote the transitively pinned dependencies to explicit dependencies in the nuspec.
+
+In the following example, `PackageA 1.0.0` has a dependency on `PackageB 1.0.0`.
+
+```xml
+<Project>
+  <ItemGroup>
+    <PackageVersion Include="PackageA" Version="1.0.0" />
+    <PackageVersion Include="PackageB" Version="2.0.0" />
+  </ItemGroup>
+</Project>
+```
+
+```xml
+<Project Sdk="Microsoft.NET.Sdk">
+  <PropertyGroup>
+    <CentralPackageTransitivePinningEnabled>true</CentralPackageTransitivePinningEnabled>
+    <TargetFramework>net6.0</TargetFramework>
+  </PropertyGroup>
+  <ItemGroup>
+    <PackageReference Include="PackageA" />
+  </ItemGroup>
+</Project>
+```
+
+When you use the pack command to create a package, both packages will appear in the dependency group.
+
+```xml
+      <group targetFramework="net6.0">
+        <dependency id="PackageA" version="6.12.1" exclude="Build,Analyzers" />
+        <dependency id="PackageB" version="6.12.1" exclude="Build,Analyzers" />
+      </group>
+```
+
+Because of this, the use of transitive pinning should be carefully evaluated when authoring a library as it may lead to dependencies you did not expect.
+
 ## Overriding package versions
 
 You can override an individual package version by using the `VersionOverride` property on a `<PackageReference />` item. This overrides any `<PackageVersion />`
@@ -176,6 +221,7 @@ If you'd like to disable central package management for any a particular project
 ```
 
 ## Global Package References
+
 > [!Note]
 > This feature is only available in Visual Studio 2022 17.4 or higher, .NET SDK 7.0.100.preview7 or higher, and NuGet 6.4 or higher.
 

docs/hosting-packages/Overview.md

@@ -39,5 +39,6 @@ There are also several other NuGet hosting products such as [Azure Artifacts](ht
 - [ProGet](https://inedo.com/proget) from Inedo
 - [Sleet](https://github.com/emgarten/sleet), an open-source NuGet V3 static feed generator
 - [TeamCity](https://www.jetbrains.com/teamcity/) from JetBrains.
+- [RepoFlow](https://www.repoflow.io), a simple and easy-to-use package management platform.
 
 Regardless of how packages are hosted, you access them by adding them to the list of available sources in `NuGet.Config`. This can be done in Visual Studio as described in [Package Sources](../consume-packages/install-use-packages-visual-studio.md#package-sources), or from the command line using [`nuget sources`](../reference/cli-reference/cli-ref-sources.md). The path to a source can be a local folder pathname, a network name, or a URL.

docs/reference/cli-reference/cli-ref-sources.md

@@ -107,5 +107,7 @@ nuget sources Enable -Name "nuget.org"
 
 nuget sources add -name foo.bar -source C:\NuGet\local -username foo -password bar -StorePasswordInClearText -configfile %AppData%\NuGet\my.config
 
+nuget sources add -name MyAzureDevOpsSource -source "https://pkgs.dev.azure.com/yourorgname/yourprojectname/_packaging/yourfeedname/nuget/v3/index.json" -username ignored -password <Personal Access Token>
+
 nuget sources Update -Name "nuget.org" -ProtocolVersion 3
 ```