50 ‐ About versions, releases and builds

Production / stable releases

The stable releases are tagged with semantic release / versioning notions. You may find X.Y.Z tags for production releases. These are production versions. These tags are defined using the GitHub releases.

The production builds are made using our CI/CD pipeline. The builds of the design system toolbox app are available through the AppStore (unlisted app).

For example a stable release of version v0.20.0 
will have a tag 0.15200 for the Swift package
and if possible a tag 0.20.0 for the design system toolbox app
with associated releases

In fact, the design system toolbox app has production releases, as an image of the library production release. The most interesting thing is the library version ; any production build is tagged and considered frozen.

Note

This operation is partialy automatic. Releases are done in both Swift package and demo app repos.

Release candidates

We can make release candidate, without release. It means the release will come soon and is considered enough stable to be shipped. We add tags with the -rc suffix with an integer value in the end, starting by 1, and incremented by 1 at each step.

For example a release candidate for a futur production release of version v0.20.0 
will have a tag 0.20.0-rc1, then maybe 0.20.0-rc2, etc.

Note

This operation is not automatic. Such tags / release candidates are done only in the Swift package repo.

Beta / nightly builds, snapshots tags

Our CI/CD pipeline make nightly builds each night for beta versions. The builds are available through TestFlight and are considered as beta builds. Snapshots tags are made for each builds: a ci tags and a Test_Flight tag. They are suffixed by the commit hash which has been pull for builds. In theory, a ci tag means the stuff has already be built, and the Test_Flight tag means the build has been uploaded. No releases on GitHub are created here, only lightweight tags.

For example a commit of hash 1ebf090fd64fc02e0a11c59296e3c32749e1351e
will have two snapshot tags: ci/1ebf090 and Test_Flight/1ebf090, 
and will be used for a beta release during a nightly build

In few words, each night we build new stuff and people can test as beta previews.

Note

This operation is automatic. This operation is done on the demo app repo (since #187)

Alpha builds

Our CI/CD pipeline can make alpha builds using branches to pull and build. The builds are available through TestFlight. No tags nor release nor snapshots are done for alpha builds. Only on-demand builds. There are for people wanting to test the app as is, for some feature being implemented or needed to be reviewed before any merge. For example, accessibility experts, designers and product owner can ask for alpha builds.

Note

This operation is not automatic. This operation is done on the demo app repo considering it points to the suitable Swift package branch

The Swift package can be alpha tags if needed.

---

Tip

In few words, use stable versions for frozen library, release candidates for almost stable versions, beta (nightly) for the quite up-to-date code based but maybe more unstable than release candidates and alpha for on-demand build to test some evolutions