Summary

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.

Additional labels for pre-release and build metadata are available as extensions to the
MAJOR.MINOR.PATCH (x.y.z) Format.

Semantic Versioning

● A normal version number MUST take the form X.Y.Z where X, Y, and Z are
non-negative integers, and MUST NOT contain leading zeroes. X is the major
version, Y is the minor version, and Z is the patch version. Each element MUST
increase numerically. For instance: 1.9.0 -> 1.10.0 -> 1.11.0

● Once a versioned package has been released, the contents of that version MUST
NOT be modified. Any modifications MUST be released as a new version. To make
changes create a new version corresponding to the released version.

○ if 1.0.0 is released in prod and has bugs. Create a new version 1.0.1 from
released version (1.0.0)
○ If it is a minor release then create a new version (1.1.1) from the latest (1.0.1)
released branch.

Github flow from new version creation.

● CODE-FREEZE
○ Source => Develop
○ Target => current Sprint (1.0.0)
 ● BACKMERGE
○ Source => current Branch (Released Branch)
○ Target => Develop

● CREATE TAG-Remove Source

○ Source => current Branch ( 1.0.0)
○ Reference => current Branch (1.0.0)

Prod deployment process :

● QA deploys branches of respective modules to Staging.

● Once QA approval is sent with respective modules & branch names.
● Run workflow and push image to docker registry.
● Make necessary property file changes in git for this sprint.

As soon as PROD deployment has finished follow the following process :

● Start BackMerge
● CREATE TAG-Remove Source Branch

New Sprint process :

● Verify whether all minor, major or bug fixes have been back merged or not.
● Before code-freeze for new sprint respective modules & sprint tag will be
Supplied.
● Sprint tag would be next version of shermac-fe like 2.0.0 if last was 1.0.0

New Hotfix/Minor release branch.

● For every email for hotfix/minor release, module name & branch will be given.
● Go to GIT.
● Search for Module name
● Go to branches.
● Create a Branch with the given name from the main (latest) branch.
● Like if a 1.0.2 hotfix branch has to be created for the Shermac FE, create a branch
1.0.2 from 1.1.0 or 1.1.0 from 1.0.0 & so on. Always create branches in an
incremental way.

ENV file changes for a Sprint :

● Till Staging, make necessary changes as asked by devs.
● For Production, ask dev whether the changes shall go to PROD or not.
● If yes, note down the env file changes made in staging in the safe zone.
● Then on process to PROD deployment ask devs to provide correct values for env
files.
 ● Keep Note that env files changes in staging might not have values that should be
included in PROD. So we must ask for new values.

New Hotfix/Minor release branch :

● For every email for hotfix/minor release, module name & branch will be given.
● Go to GIT
● Search for Module name
● Go to branches.
● Create a Branch with the given name(1.0.1 or 1.1.0) from the released branch.
● Like if a 1.0.2 hotfix branch has to be created for the shermac FE module, create a
branch 1.0.2 from 1.0.1 or 1.0.1 from 1.1.0 & so on. Always create branches in an
incremental way.

Life-Cycle for a sprint :

● Code-Freeze
● Stage deployment
● BackMerge
● Create Tag
● Hotfix Branch
● BackMerge
● Create Tag

Some Terminology

BackMerge - it just means to do a merge, like any other, but in a direction that is
"backwards" compared to the normal flow of the branching conventions.

CodeFreeze - Code Freeze means the code is frozen and there will not be any further
modifications from the developers. After the code freeze, the code should not be changed by
the developers.