-
Notifications
You must be signed in to change notification settings - Fork 1
50 ‐ About versions, releases and builds
The production 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 are available through TestFlight.
For example a production release of version v0.4.0
will have a tag 0.4.0 and a release on GitHub
In fact, the demo 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.
We can make release candidate tags, without release. It means the release will come soon and is considered enough stable to be shipped. We add 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.4.0
will have a tag 0.4.0-rc1, then maybe 0.4.0-rc2, etc.
Our CI/CD pipeline make nightly builds each night.
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 snpashot 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.
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. 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.