Branch and tag naming strategies for maintaining the project

Owned by Rahul Shinde, created
Jul 13, 2021
2 min read

Driver

Approver

Contributors

Stakeholder

Driver

Approver

Contributors

Stakeholder

 

 

 

Objectives

  1. Branch naming patterns

  2. Releases with tags

  3. Backward compatibility

Due date

Jul 10, 2021 

Key outcomes

  • Adaption of Semantic version

  • Laying out the path for release cycles

Status

Not started

Introduction

Why we need the naming strategies for git branches and tags?

  1. We added composer support for creating new projects and maintaining the old ones.

  2. Use of the SemVer aka Semantic Versioning

  3. Adding backward compatibility with the help of deprecations.

  4. Less burden on Release managers.

Current Branches

The following table shows the releases and branches.

Branch

RC Release

Initial Release

Active Support Until

Security Support Until*

Branch

RC Release

Initial Release

Active Support Until

Security Support Until*

2.15

27 Sep 2019

8 Oct 2019

8 Oct 2019

8 Oct 2019

2.16

30 Jan 2020

13 Feb 2020

15 June 2020

15 December 2020

3.x

27 Jan 2020

15 June 2020

15 June 2021

15 December 2021

3.1

17 Aug 2020

24 Aug 2020

23 Nov 2020

30 Nov 2020

3.2

23 Nov 2020

30 Nov 2020

16 Feb 2021

22 Feb 2021

3.3

16 Feb 2021

22 Feb 2021

17 May 2021

24 May 2021

4.x

17 May 2021

24 May 2021

24 May 2022

20 Dec 2022

Proposed Solution

Use of the Semantic Version

  • The development will be done on branches with naming pattern Major.Minor

  • Releases will be done using tags with pattern Major.Minor.Patch

Branches ⬇️

Tags⬇️

Major

Minor

Branch

Branches ⬇️

Tags⬇️

Major

Minor

Branch

 

4.x.x

  • Symfony Upgrade

  • Major API change

  • Removal of deprecations

  • Adding features with backward copatibulity

  • Bug fixes

3.0

 

Symfony 3

 

 

4.0

4.0.0

  • Symfony 4

  • Composer Support

 

 

4.0

4.0.1

 

 

Bug Fixes

4.1

4.1.0

 

Adding GrapeJS

 

5.0

5.0.0

  • Symfony 5

  • Removal of deprecations

 

 

 

The Development

With this, the development will be done on the Major.x branch, where Majoris the major version and x denotes the development mode. The Major.x will have the following,

  • Adding new feature

  • bug fixes

  • Depreciation and Backward compatible code

The Release

We will use the git tags for releases. The pattern will be Major.Minor.Patch.

  • Patch release includes the bug fixes and will be safe to upgrade. e.g. 4.1.1, 5.0.2, etc.

  • The minor release includes bug fixes and new features, which are safe to upgrade. e.g. 4.5, 5.1, etc.

  • The major release includes the breaking changes, like kernel upgrade, API changes. And comes with an upgrade path from a previous major. e.g. 4.0, 5.0 etc.

For example,

We are working 3.x cycle and along with this, we have started with the 4.x. The following will be the life cycle of releases,

  • Once our 4.x branch is stable we release 4.0.0. While releasing Release maintainer should not merge any PR to the 4.x branch. With this, we have two releases one is 4.x and 4.0.0.

  • For the new feature to add, we will follow the Git Feature Branch Workflow. i.e. developers will create a feature branch and make that available for others to participate. Once the development and testing are completed, we will merge the feature branch to 4.x and release the next minor release.

Reference materials

The followings are the referred links,