save

Author: Rami Bououni

docs/artifacts/concepts/upstream-sources.md

@@ -1,10 +1,10 @@
 ---
 title: What are upstream sources?
-description: Understand Azure Artifacts upstream sources
+description: Learn what is Azure Artifacts upstream sources, their benefits for package management, and recommended best practices.
 ms.assetid: 7cb70122-7c5b-46c1-b07e-1382cfc7d62b
 ms.service: azure-devops-artifacts
 ms.topic: overview
-ms.date: 03/05/2025
+ms.date: 09/11/2025
 monikerRange: '>= azure-devops-2020'
 "recommendations": "true"
 ---
@@ -13,29 +13,29 @@ monikerRange: '>= azure-devops-2020'
 
 [!INCLUDE [version-gt-eq-2020](../../includes/version-gt-eq-2020.md)]
 
-Azure Artifacts upstream sources enable developers to conveniently store packages from various sources in a single feed, including those you publish and those installed from external feeds or public registries like NuGet.org, npmjs.com. Once upstream sources are enabled, any package installed from an upstream source is automatically saved to your feed.
+Azure Artifacts upstream sources allow developers to store packages from various origins in a single feed, including packages published to the feed and those installed from public registries like *NuGet.org* or *npmjs.com*. Once upstream sources are enabled, any package installed from an upstream source is automatically saved to your feed
 
 [!INCLUDE [save-requires-collaborator](../includes/save-requires-collaborator.md)]
 
 ## Why use upstream sources?
 
-Enabling upstream sources provides several benefits for managing your product’s dependencies within a single feed:
+Enabling upstream sources offers several advantages for managing your product’s dependencies within a single feed:
 
-- **Simplicity**: Storing all your packages in a single feed simplifies your configuration files like NuGet.config, npmrc, or settings.xml. With just one feed in your config file, you reduce the chances of errors and streamline your setup.
+- **Simplicity**: Storing all your packages in a single feed simplifies your configuration files like *NuGet.config*, *npmrc*, or *settings.xml*. With just one feed in your config file, you reduce setup complexity and minimize errors.
 
-- **Consistent Builds**: Your feed resolves package requests in a defined order, ensuring more predictable and reliable builds.
+- **Consistent Builds**: Your feed resolves package requests in a defined order, helping ensure predictable and reliable builds across environments.
 
 - **Package Integrity**: Your feed retains metadata about packages saved from upstream sources, allowing you to verify their authenticity and ensure you're using the original versions, not copies or potentially malicious versions.
 
-- **Reliability**: Packages installed from upstream sources are automatically saved to your feed. This ensures continued access even if the upstream source becomes unavailable due to maintenance or other issues so you can continue developing and building with confidence.
+- **Reliability**: Packages installed from upstream sources are automatically saved to your feed. This ensures continued access even if the upstream source becomes temporarily unavailable due to maintenance or other issues so you can continue developing and building with confidence.
 
 ## Best practices for package consumers
 
 To take full advantage of the benefits of upstream sources as a package consumer, follow these best practices:
 
-#### 1. Use a single feed in your config file
+#### 1. Use a single feed in your configuration file
 
-In order for your feed to provide a [deterministic restore](#search-order), make sure that your configuration file (such as nuget.config or npmrc) references only one feed with upstream sources enabled. 
+In order for your feed to provide a [deterministic restore](#search-order), make sure that your configuration file (such as *nuget.config* or *npmrc*) references **only one feed** with upstream sources enabled. 
 
 - **Examples**:
 
@@ -56,20 +56,23 @@ In order for your feed to provide a [deterministic restore](#search-order), make
 
 #### 2. Order your upstream sources intentionally
 
-If you’re only using public registries like NuGet.org or npmjs.com, the order of your upstream sources doesn’t matter. Requests to the feed follow the sequence outlined in the [search order](#search-order) section.
+If you're using only public registries like *NuGet.org* or *npmjs.com*, the order of upstream sources doesn’t affect behavior. Requests to the feed follow the sequence outlined in the [search order](#search-order) section.
 
-However, when you're managing multiple sources, such as a combination of feeds and public registries, each upstream source is searched in the order defined in the feed’s configuration settings. In this case, we recommend placing the public registries first in the list of upstream sources.
+However, when managing multiple sources, such as a combination of feeds and public registries, each upstream source is searched in the order defined in the feed’s configuration settings. In these cases, we recommend placing the public registries first in the list of upstream sources.
 
-In some unique scenarios, some organizations modify open-source software (OSS) packages to address security concerns, enhance functionality, or meet specific internal  requirements that require rebuilding the package internally rather than obtaining it directly from a public repository. 
-If your organization follows this practice, place the upstream source containing these customized OSS packages before other public registries. This ensures your customized versions are used instead of public ones.
+In some unique scenarios, some organizations modify open-source software (OSS) packages to address security concerns, enhance functionality, or meet specific internal requirements that require rebuilding the package internally rather than obtaining it directly from a public repository. 
+If your organization follows this practice, place the upstream source containing these customized OSS packages before other public registries. This ensures your customized versions are used instead of the public ones.
 
 ## Best practices for feed owners and package publishers
 
 To ensure your feed can be easily configured as an upstream source, follow these best practices:
 
 #### 1. Use the default view
 
-The default view for all newly created feeds is `@Local`, which contains all the packages published to your feed as well as packages saved from upstream sources.
+All newly created feeds use the `@Local` view by default. This view includes:
+
+- Packages published directly to the feed.
+- Packages saved from upstream sources.
 
 If you want to use other views such as a view for newly released package versions, you can promote your packages to the `@Release` view and then make that view available to your target consumers. See [Feed views](views.md) for more details.
 
@@ -81,7 +84,7 @@ To construct a package graph, simply connect to the feed's default view and inst
 
 For public package managers that support multiple feeds, such as NuGet and Maven, the order in which feeds are queried can sometimes be unclear or nondeterministic. For example, NuGet sends parallel queries to all the feeds in the configuration file and processes responses in a first-in, first-out (FIFO) manner, which can lead to inconsistent results.
 
-Upstream sources eliminate this uncertainty by enforcing a structured search order, by searching the feed and its upstream sources in the following order:
+Azure Artifacts upstream sources eliminate this uncertainty by enforcing a structured search order, by searching the feed and its upstream sources in the following order:
 
 1. Packages that have been published directly to the feed.
 
@@ -90,15 +93,15 @@ Upstream sources eliminate this uncertainty by enforcing a structured search ord
 1. Packages available from upstream sources. Each upstream source is searched in the order it's listed in the feed's configuration.
 
 > [!NOTE]
-> Azure Artifacts does not support searching for packages in upstream sources using the NuGet Package Explorer in Visual Studio.
+> Azure Artifacts does not support searching for packages in upstream sources using the **NuGet Package Explorer** in Visual Studio.
 
 ## Save packages from upstream sources
 
-When an upstream source is enabled on your feed, Azure Artifacts will automatically save a copy of any package installed by a collaborator or higher from upstream.
+When an upstream source is enabled on your feed, Azure Artifacts automatically saves a copy of any package installed by a collaborator or higher from that upstream source.
 
-For instance, you can install packages directly from the upstream source using a command like *npm install express*. Alternatively, packages might be installed as part of a dependency resolution process. In this case, installing *express* would also save its dependencies, such as *accepts*. 
+For example, you can install packages directly from the upstream source using a command like *npm install express*. Alternatively, packages might be installed as part of dependency resolution, so installing *express* would also save its dependencies, such as *accepts*.
 
-Upstream sources provide an important safeguard for your consumers and infrastructure, protecting them from unexpected outages. If the upstream source experiences downtime, maintenance, or becomes temporarily unavailable, you can still retrieve the necessary packages from your feed and continue your development.
+Upstream sources offer a critical safeguard for your consumers and infrastructure. If the public registry experiences downtime, maintenance, or becomes temporarily unavailable, you can still retrieve the necessary packages from your feed and continue your development.
 
 ::: moniker range="azure-devops"