Skip to content
This repository has been archived by the owner on Jun 1, 2024. It is now read-only.

Release

paulomeurerzup edited this page Jan 8, 2021 · 10 revisions

The Beagle framework have two types of releases: normal and hotfix.

When do we release a normal version?

Normal releases are made when we have major or minor changes in the framework.

When do we release a hotfix version?

Hotfix releases are made when we have patch changes in the framework. Usually we have hotfixes for specific platforms.

What is major, minor and patch?

The Beagle framework uses semantic versioning. Given a version number MAJOR.MINOR.PATCH, increment the:

  1. MAJOR version when you make incompatible API changes,
  2. MINOR version when you add functionality in a backwards compatible manner, and
  3. PATCH version when you make backwards compatible bug fixes.

You can see more about semantic versioning here.

How do I release a version?

The release process is divided in two steps:

  1. Create GitHub release

This step is done manually.

  1. 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.

1. Create GitHub release

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.

Naming conventions

We have some naming conventions that must be followed:

Normal Relase

Branches

For normal releases, you will always use master branch.

Tags

Your tags must have the following name format: *.*.* e.g. 1.3.0

Hotfix Release

Branches

Your branch must have the following name format: release/*.*.*-'platformName' e.g.

release/*.*.*-android
release/*.*.*-ios
release/*.*.*-backend
release/*.*.*-flutter
Tags

Your tags must have the following name format: *.*.*-'platformName' e.g.

*.*.*-android
*.*.*-ios
*.*.*-backend
*.*.*-flutter

How to create a new Github Release

This is the step-by-step to create a new GitHub release.

1. Create a release branch

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.

2. Merge PRs

Merge all needed pull requests to the release branch created in step 1.

3. Create a new release in GitHub

How to create a new release:

  1. At the starter page of the repository, select Releases -> Draft a new Release
  2. Tag Version

IMPORTANT! Tag version must follow tag naming conventions for specific release type.

  1. 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.

  1. 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.

  1. Description

It could be left empty. The release description is generated automatically by fastlane-plugin-semantic_release plugin.

  1. 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.

2. Compile and Deploy

This step is automatically executed after publishing the GitHub release.

How does it works?

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:

Clone this wiki locally