-
Notifications
You must be signed in to change notification settings - Fork 90
Release
The Beagle framework have two types of releases: normal
and hotfix
.
Normal releases are made when we have major
or minor
changes in the framework.
Hotfix releases are made when we have patch
changes in the framework. Usually we have hotfixes for specific platforms.
The Beagle framework uses semantic versioning. Given a version number MAJOR.MINOR.PATCH, increment the:
- MAJOR version when you make incompatible API changes,
- MINOR version when you add functionality in a backwards compatible manner, and
- PATCH version when you make backwards compatible bug fixes.
You can see more about semantic versioning here.
The release process is divided in two steps:
- Create GitHub release
This step is done manually.
- Compile and Deploy
This step is automatically executed after publishing the GitHub release. To compile and deploy the release we use GitHub Actions, fastlane and bash scripts.
The first step to release a version is to create a Github release. To accomplish this step, you must know some naming conventions used for branches and tags.
We have some naming conventions that must be followed:
For normal releases, you will always use master
branch.
Your tags must have the following name format:
*.*.*
e.g.
1.3.0
Your branch must have the following name format:
release/*.*.*-'platformName'
e.g.
release/*.*.*-android
release/*.*.*-ios
release/*.*.*-backend
release/*.*.*-flutter
Your tags must have the following name format:
*.*.*-'platformName'
e.g.
*.*.*-android
*.*.*-ios
*.*.*-backend
*.*.*-flutter
This is the step-by-step to create a new GitHub release.
IMPORTANT! This step is only needed for hotfixes. Normal releases will always point to
master
branch.
When releasing a hotfix, you must create a branch for the release. This branch usually will be created from the latest version.
The latest version could be a normal version like 1.3.0 or a previous hotfix like 1.3.1-'platformName'.
IMPORTANT! You must observe branch naming conventions for hotfixes.
Merge all needed pull requests to the release branch created in step 1.
How to create a new release:
- At the starter page of the repository, select
Releases -> Draft a new Release
- Tag Version
IMPORTANT! Tag version must follow tag naming conventions for specific release type.
- Target
Hotfix: The target always will be the branch created on step 1. Create a release branch.
Normal: The target always will be
master
branch.
- Release title
As a convention, the release title follows the pattern:
*.*.* ('platformName')
for hotfix release and*.*.*
for normal release. By the way, its just a convention due the fact that the release title will be overwritten by fastlane script.
- Description
It could be left empty. The release description is generated automatically by fastlane-plugin-semantic_release plugin.
- Click publish
The publish action will create a tag with specific name created in tag version (step 2) and consequently start the Github Actions workflow.
This step is automatically executed after publishing the GitHub release.
When you publish a release in GitHub, it will generate a tag with the name provided in the Tag Version
field and push the content of Target
field branch to this generated tag.
In Beagle GitHub Actions we have a workflow called release
. This workflow will be triggered every time a push
event occurs to any tag in the repository. You can see it more detailed in the workflow file.
This workflow starts a job that creates some needed environment variables and executes the fastlane deploy
lane. You can see it more detailed in the Fastfile.
When we have a normal release all workflows bellow are triggered and when we have a hotfix for a platform, only the platform specific workflow will be triggered.
You can see the complete workflow for each specific platform in links bellow: