Feeds, views and upstream packages
Design and implement package feeds and views
Feed scope — and the one-way door
| Scope | Visible from | Note |
|---|---|---|
| Project-scoped | The hosting project only | Only these can be public feeds (in a public project) |
| Organization-scoped | Any project in the organisation | Cannot be converted to project-scoped |
That conversion restriction is a genuine design decision, not trivia: choosing organisation scope is irreversible, so scope deliberately at creation time.
Private feeds require authenticated users with at least Feed Reader permission.
Views
Every feed ships with three views: @local, @prerelease, @release. The latter two are suggestions you may rename or delete; @local is the default.
Two rules that catch people:
Feed views are read-only. A consumer connected to a view can only use packages published to it or previously saved from upstream.
Packages can only be published to the base feed, where they appear in
@local. You cannot publish directly into@release.
So promotion is not a publish — it is promoting an existing package version into a view. @local therefore contains everything: packages published to the feed plus all packages saved from upstream sources.
Views + upstream together
To let another feed consume yours as an upstream source, set your feed's visibility to members of your organization or members of your Microsoft Entra ID. That combination — a curated @release view, consumed upstream by other feeds — is the enterprise sharing pattern.
Primary sources