AZ-400 Question 105
Single answerYour organization has a microservices architecture where each service depends on a common shared library. Historically, the library used Semantic Versioning (SemVer) to communicate backward-incompatible changes. However, your leadership wants to release new modules and enhancements on a time-based schedule every quarter. They are discussing switching entirely to date-based versioning (CalVer) for all code assets. Which strategy best meets both the need to indicate breaking changes and the need for predictable release timelines?
- A
Adopt a pure date-based versioning model (CalVer) for every release, replacing SemVer completely to focus on scheduled milestones.
- B
Use SemVer for all builds but reset the major version number every quarter to reflect the scheduled release cycle.
- C
Continue using SemVer for libraries to clearly indicate breaking changes, while attaching date-based version identifiers at the CI/CD pipeline level or as release metadata.
- D
Maintain parallel versioning schemes for every release�one using SemVer for developers to track compatibility and another using CalVer for management oversight.
Show answer and explanation
Correct answer: C
Explanation
In most real-world DevOps scenarios, Semantic Versioning (SemVer) is critical for communicating to consumers of a library when a release contains potentially breaking changes. However, teams often also want to align their release cycles with predictable schedules. The recommended practice is to maintain SemVer for compatibility signaling while using date-based markers (CalVer) at the pipeline or metadata level to align with organizational release plans. Refer to semver.org and official Azure DevOps documentation for more on best practices regarding semantic and date-based versions.
- A. Incorrect.
Incorrect: While date-based versioning can simplify scheduling, removing SemVer entirely makes it difficult for developers to quickly identify backward-incompatible changes. Relying only on dates could lead to confusion about compatibility.
- B. Incorrect.
Incorrect: Resetting the major version regularly undermines SemVer� core principle of indicating breaking changes. This approach may cause confusion because a new major version might not always introduce incompatibilities.
- C. Correct.
Correct: SemVer remains the best option for signaling backward-incompatible changes and forcing clients to acknowledge potential breaking updates. Date-based identifiers can be appended at the pipeline level to meet scheduled release needs without losing the benefits of SemVer.
- D. Incorrect.
Incorrect: Having two distinct production-facing version systems on the same artifact can be unnecessarily complex. This might confuse consumers who are unsure which version scheme to track for compatibility and updates.