Implementing Semantic Versioning Principles

Table of Contents

1. Challenge

   Access the terminal and initialize the versioned project

   Open the Ubuntu Console from the lab environment, verify that Git is available, configure your commit identity, and initialize the repository with the first version of the shared library.

2. Challenge

   Tag the initial stable release as version 1.0.0

   A semantic version has three fields, MAJOR.MINOR.PATCH. MAJOR increases when a release breaks existing consumers, MINOR increases when a release adds functionality that existing consumers can ignore, and PATCH increases when a release only fixes behavior. The library interface is now stable enough for other teams to depend on, so version 1.0.0 marks the first interface that consumers can depend on. Record the reason in a changelog and create an annotated tag that marks the release.

3. Challenge

   Increment the patch version for a backward-compatible fix

   A consumer reports that resource_count always returns 1 instead of the number of resources. The fix corrects the behavior without changing any function name or parameter, so it is a patch release.

4. Challenge

   Increment the minor version for backward-compatible functionality

   Another team wants to filter the resource list by a name prefix. Adding a new function gives them that capability while every existing function keeps working, so this is a minor release.

5. Challenge

   Increment the major version for a breaking change

   The team decides that every resource lookup must be scoped to an environment. This means renaming list_resources to get_resources and requiring an environment argument. Existing consumers that call list_resources will break, so this is a major release.

6. Challenge

   The last objective

   Welcome to the final objective! This is your last chance to experiment in the environment. Clicking End Lab will end this little world that flittered into existence just for you.