Views communicate the quality of a package version, which SemVer numbers cannot do because quality is only known after validation. They act as read-only release channels over the same feed.
Every feed has three views: @Local, @Prerelease and @Release. @Local is the default view and contains everything published directly to the feed plus everything saved from upstream sources. @Prerelease and @Release are suggested views that you can rename or delete, and you can add more. All views support NuGet, npm, Maven, Python, Cargo and Universal Packages.
Rules to remember:
- Packages can only be published to the base feed, where they appear in
@Local. Changing the default view (Feed settings > Views) does not enable publishing directly to that view. - Views are read-only to consumers; they see only versions promoted to the view (and packages previously saved from upstreams).
- Promotion requires Feed Publisher (Contributor) or Feed Owner and is done from the package page (Promote) or the REST API: a PATCH with a JSON Patch body that adds the view to the package version’s views array, using a PAT with Packaging Read, write, & manage.
- There is no demotion: once promoted, a package cannot be reverted to a previous view or back to
@Local. - Packages promoted to any view are exempt from feed retention policies.
- For public feeds, changing a view’s access to Specific people makes it unavailable as an upstream source.
A typical flow publishes every CI build to @Local, promotes to @Prerelease after automated tests pass, and promotes to @Release after QA approval and security scanning. Consumers connect to <feed>@Release, for example https://pkgs.dev.azure.com/<org>/<project>/_packaging/<feed>@Release/nuget/v3/index.json. Figure 5.1 shows the whole path from upstream to consumer.
{
"views": { "op": "add", "path": "/views/-", "value": "Release" }
}Common trap: Configuring a pipeline to publish straight to
@Release- publishing always targets the base feed (@Local); reaching@Releaserequires a separate promotion step.