What are feed views?
TFS 2018
Feed views enable developers to share a subset of package-versions with their consumers. A common use of feed views is to share package versions that have been tested and validated but hold back on packages that are still under development and/or didn't meet a certain quality bar.
Default view
All Artifacts feeds come with three views: @local, @prerelease, and @release. The latter two are suggested views that you can rename or delete as desired. @local is the default view that's commonly used in upstream sources.
The @local view contains all packages published directly to the feed and all packages saved from upstream sources.
Feed views are read-only, which means that users connected to a view can only use packages that are published to that view and/or packages previously saved from upstream sources. See package graphs to learn how available packages are constructed.
Note
Azure Artifacts only supports publishing and restoring packages from and to the default view - @Local.
Feed views and upstream sources
Feed views and upstream sources are designed to work together to provide an enterprise-level solution to share and consume packages. In order for other Azure Artifacts feeds to use your feed as an upstream source, you must set your feed's visibility to members of your organization, or members of your Microsoft Entra ID, depending on your scenario. If you choose the latter, all people in your organization will be able to access your feed. In addition, all feeds in your organization and other organizations associated with the same Microsoft Entra tenant will be able to upstream to your feed.
Note
All feed views in a public project are accessible to everyone on the internet.
Release packages with feed views
When creating release packages, it's important to convey three pieces of information: the nature of the change, the risk of the change, and the quality of the change.
Nature and risk of the change
The nature and the risk of the change both pertain to the change itself, that is, what you set out to do, they're both known at the outset of the work. If you're introducing new features, making updates to existing features, or patching bugs; this is the nature of your change. If you're still making changes to the API portion of your application; this is one facet of the risk of your change. Many NuGet users use Semantic Versioning (SemVer) notation to convey these two pieces of information. SemVer is a widely used standard and does a good job of communicating this type of information.
Quality of the change
The quality of the change isn't generally known until the validation process is complete. This comes after your change is built and packaged. Because of this detail, it's not feasible to communicate the quality of the change in the numerical segment of the version number (e.g 1.2.3). There are workarounds to pre-validate (e.g. consume the build's DLLs directly before they're packaged and publish the packages to a "debug" or "CI" environment then validate and republish those packages to a "release" environment) but none that we've seen can truly guarantee that the built package will meet the correct quality standard.
You can use the @Release view as a means to convey the quality of your changes. Using the @Release view, you can share packages that met your quality bar and allow your consumers to only see the subset of package versions that were tested, validated, and are ready to be consumed.
