-
Notifications
You must be signed in to change notification settings - Fork 6
50 ‐ About versions, releases and builds
Tip
In few words, use stable releases for frozen product (x.y.z), release candidates for almost stable versions (-rc), beta releases (-beta) for a bit up-to-date code base but maybe more unstable than release candidates. SNAPSHOT is always the last state of the codebase in develop version. beta (-beta) releases are for beta versions of the codebase. alpha (-alpha) releases are rare and are for alpha versions of the codebase, can be done on demande Beta / snapshots builds are linked and associated to a nightly tag (ci/, Test_Flight/) Alpha builds do not have alpha tag and are builds for specific features. Stable releases, and lots of commits can be cryptographically signed.
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 linked to the GitHub releases.
They can be created in the same time as the GitHub release (in that case not cryptographically signed) or before (and can be cryptographically signed by library maintainers).
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.20.0 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 partially automatic. Releases are done in both Swift package and design system toolbox app repositories.
We can make release candidate releases, without properly GitHub release. It means the release will come soon and is considered almost 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 future production release of version v0.20.0
will have a tag 0.20.0-rc.1, then maybe 0.20.0-rc.2, etc.
Note
This operation is not automatic. Such tags / release candidates are done in the Swift package repo and the design toolbox repo to keep things clear. They are not linked to special builds; but nightly builds can bring release candidates.
Our CI/CD pipeline makes nightly builds each night for snapshots builds (called also in OUDS context beta builds).
The builds are available through TestFlight and are considered as snapshots / 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 / snapshot build 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 design system toolbox repository. It was before done on the Swift Package repository when the app was hosted inside it.
Note
Snapshots release are prefixed by ci/ But we can still create beta releases suffixed by -beta. They can be used if some users need beta releases.
Our CI/CD pipeline can make alpha builds using branches to pull and build. The builds are available through TestFlight. 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 design system toolbox app repoistory considering it points to the suitable Swift package branch
Note
In some rare conditions there can be alpha releases of the Swift package suffixed by -alpha
Commits are mainly cryptographically signed, and also tags. This can be verified. You can get more details on GitHub documentation.
GitHub can sign some commits automatically, like web-based commits.
To verify their cryptographic signatures:
- Download the GitHub web-flow dedicated key at https://github.com/web-flow.gpg (supposing here named when downloaded 'web--flow.gpg')
- Import the key in your GPG key chain with command
gpg --import web-flow.gpg - Of course a GPG solution like
gnupgmust be installed in your computer - Run the Git verification command (
git verify-commit hash,git verify-tag name, orgit log -v --show-signature) and check the results
- For @pylapp, get the key from openpgp.og
- Import it with
gpg --importcommand - Run the Git verification command (
git verify-commit hash,git verify-tag name, orgit log -v --show-signature) and check the results
For example, result can be like:
> git verify-tag 0.21.0
gpg: Signature faite le mer. 5 nov. 17:27:35 2025 CET
gpg: avec la clef EDDSA 8030BBE06B4F48F95BD082DA7D5AE4DCFF3A3435
gpg: Bonne signature de « Pierre-Yves Lapersonne (Orange) (Clé GPG professionnelle en tant qu'employé Orange) <[email protected]> » [inconnu]
gpg: Attention : cette clef n'est pas certifiée avec une signature de confiance.
gpg: Rien n'indique que la signature appartient à son propriétaire.
Empreinte de clef principale : 8030 BBE0 6B4F 48F9 5BD0 82DA 7D5A E4DC FF3A 3435
- Get and import the GPG public key as explained above
- Download the artifact from the release and the associated .asc file
- Run command and check result of
gpg --verify artifact.asc artifact.zip
For example, result can be like:
> gpg --verify ouds-doccarchive.zip.asc ouds-doccarchive.zip
gpg: Signature faite le mar. 11 nov. 23:22:04 2025 CET
gpg: avec la clef EDDSA 8030BBE06B4F48F95BD082DA7D5AE4DCFF3A3435
gpg: Bonne signature de « Pierre-Yves Lapersonne (Orange) (Clé GPG professionnelle en tant qu'employé Orange) <[email protected]> » [inconnu]
gpg: Attention : cette clef n'est pas certifiée avec une signature de confiance.
gpg: Rien n'indique que la signature appartient à son propriétaire.
Empreinte de clef principale : 8030 BBE0 6B4F 48F9 5BD0 82DA 7D5A E4DC FF3A 3435
Because we use immutable releases in GitHub, the integrity of the releases and the associated artifacts can be checked:
To verify integrity of a release x.y.z:
gh release verify x.y.z --repo Orange-OpenSource/ouds-iosResult can be like:
> gh release verify 0.21.0 --repo Orange-OpenSource/ouds-ios
Resolved tag 0.21.0 to sha1:a3da5c01b26214f3a01fd5327f9d3a3c53757a2f
Loaded attestation from GitHub API
✓ Release 0.21.0 verified!
Assets
NAME DIGEST
ouds-doccarchive.zip sha256:e393311de5f8bd24ce71373c1ca8db427146d99ce7ccb9cb4c3392d3e6729677
ouds-ios-gh-pages.zip sha256:2b9308fa1188594951b35707ae58e6051782ad21712cd589194eeb3c1c1d6fd7
ouds-ios.wiki-assets.zip sha256:e7115a2431f432c7d4e54dbb842a4441e62b390f7f52b5d9a66eb2ce34b99334
ouds-ios.wiki.zip sha256:722f4904448b0a400e948dd56da3b5b07019f97c3027d8bea93ba23afe41500d
Tutorial.doccarchive.zip sha256:4f5cc2dd33f581ac596c708233bbb819f91b86f3cf1b3b4eb2326f501e34d328
To verify integrity of an asset (previously downloaded at current location) associated to the release x.y.z:
gh release verify-asset x.y.z asset --repo Orange-OpenSource/ouds-iosResult can be like:
> gh release verify-asset 0.21.0 ouds-doccarchive.zip --repo Orange-OpenSource/ouds-ios
Calculated digest for ouds-doccarchive.zip: sha256:e393311de5f8bd24ce71373c1ca8db427146d99ce7ccb9cb4c3392d3e6729677
Resolved tag 0.21.0 to sha1:a3da5c01b26214f3a01fd5327f9d3a3c53757a2f
Loaded attestation from GitHub API
✓ Verification succeeded! ouds-doccarchive.zip is present in release 0.21.0
For these commands a message should say release is verified or asset verification succeeded.