L7. Package Management: GitHub Packages, Azure Artifacts & Versioning Strategies
Upstream sources insulate builds from public registry outages, feed views promote packages without duplicating them, and SemVer vs CalVer is a consumer-facing decision, not just a technical one.
Package Feeds: Centralize Dependency Management
Modern software projects depend on dozens or hundreds of external packages (libraries, frameworks, tools). Where do these packages live, and how do you keep your builds reliable when public registries might be unavailable? Azure Artifacts is a fully managed package feed service that hosts NuGet, npm, Maven, Python, and universal packages in one place. GitHub Packages hosts container images via GitHub Container Registry (GHCR) and language packages tightly integrated with GitHub repository permissions.
Both solutions let you avoid a direct dependency on public registries for every build. Instead, your build pulls packages from your internal feed, which can cache or proxy packages from the public sources.
Upstream Sources: Caching and Resilience
An upstream source in Azure Artifacts is a virtual link to a public package registry (npm, NuGet, Maven, Python registry). When your pipeline requests a package that is not yet in your feed, Azure Artifacts automatically fetches it from the upstream source and caches it locally.
The benefit is twofold: first, subsequent builds resolve that package instantly from your local feed, not the public registry. Second, if the public registry has an outage, builds can still resolve the package because it is cached locally. This is resilience without a secondary registry or manual mirroring.
Feed Views: Quality Gates Without Duplication
Azure Artifacts feed views let you promote a package through quality gates without duplicating it. A single package binary can be exposed differently depending on its promotion state:
- @Local: Packages published directly to your feed
- Prerelease: Packages that have passed initial testing but are not yet released
- Release: Packages cleared for production consumption
When a package passes validation, you promote it from @Prerelease to @Release. Consumers using the Release view see only production-ready packages, while your CI pipeline can consume the Prerelease view to test pre-release builds.
Semantic Versioning vs Calendar Versioning
A crucial exam concept: choosing a versioning scheme is not purely technical, it is a business and consumer-facing decision. Semantic Versioning (SemVer) uses MAJOR.MINOR.PATCH (e.g., 2.0.1). A MAJOR version bump signals a breaking change. If a library is on v2.1.3 and releases v3.0.0, consumers immediately understand that upgrading requires testing for compatibility breaks. SemVer is the right choice for shared libraries and frameworks where external consumers must reason about breaking changes. Calendar Versioning (CalVer) uses dates or release cadence (e.g., 2026.07.1 for July 2026, release 1). CalVer suits products where release timing matters more than API compatibility signaling. A SaaS application released weekly, an internal tool, or a product where all users upgrade in lockstep can use CalVer.
Build Numbers Are Not Package Versions
A critical distinction: a pipeline's own build number (Azure Pipelines' BuildId, GitHub Actions run number) is separate from the semantic version assigned to a package that pipeline produces.
A build can carry its own number for traceability, and the package derived from it carries a different, intentional semantic version. Conflating the two is a common design mistake that breaks consumers' ability to reason about compatibility.
| Aspect | SemVer | CalVer |
|---|---|---|
| Use Case | Shared libraries, frameworks | Products, release timing matters |
| Consumer Signal | Compatibility impact | Release timing |
| Example | 2.1.0 (breaking change if MAJOR bumps) | 2026.07.1 (released July 2026) |
- ✓Azure Artifacts upstream sources proxy and cache packages from public registries, so builds do not depend directly on public registry availability and can still resolve packages during an outage
- ✓Feed views (like @Local, @Prerelease, @Release in Azure Artifacts) let a package be promoted through quality gates without duplicating it, by changing which view exposes it
- ✓GitHub Packages hosts both container images (via GHCR) and language packages, integrated directly with a GitHub repository's existing permissions model
- ✓Semantic Versioning (SemVer) signals compatibility through MAJOR.MINOR.PATCH, making it the right choice when consumers need to reason about breaking changes; CalVer signals release timing instead and suits products where release cadence matters more
- ✓A pipeline's own build/run number is a separate concept from the semantic version assigned to a package that pipeline produces; conflating the two is a common design mistake
1. A company's build pipeline depends on public npm packages, but a public registry outage recently broke every build company-wide for hours. What Azure Artifacts feature directly addresses this risk?
2. A team wants a package to remain hidden from general consumption until it passes a validation gate, without publishing a second copy of the package. What Azure Artifacts feature supports this?
3. A software library used by many external consumers needs its version number to clearly signal whether an update contains breaking changes. Which versioning scheme is designed for this?
Recommended: Pluralsight
This free course covers the theory. Pluralsight adds structured DevOps Engineer Expert learning paths, hands-on Azure Pipelines and GitHub Actions labs, and timed practice exams to make it stick before exam day.