Release Naming and Branching

Starting June 2023, Avni is going to follow the following release naming strategy. The release has three parts - the major version, minor version and the patch fix version. Note that this is not semantic versioning.

A major release happens every 4-6 weeks. The major version is bumped up during this time. eg: 4.0.0
There might be a minor release between two major releases that consists of planned work that might need to be released sooner. This goes in a minor release. eg: 4.1.0
Urgent patches go in a patch fix release. eg: 4.0.1

Branches

Every branch comes out of the previous parent (4.1.0 comes out of 4.0.0, 4.0.1 comes out of 4.0.0).

Branches are merged to their parents, which eventually go up till the mainline.

Minor version releases
The work done in them is about 10% of what we do in a release. The release takes about 3 weeks in elapsed time, to go to production (for unavoidable reasons). For testing we need to deploy to pre-release.
(For example lets take 4.0 and 4.1)
During first and second week, we need to merge changes from 4.0 to 4.1, as some issues may block development (e.g. access control bugs) but fixed on 4.0 (via patch release work).
Releasing from 4.0 instead of 4.1 requires keeping the time duration between this merge and deploy to production no more than 1-2 days - to be able to deploy anything emergent to production. Till then we have to keep merging from 4.0 to 4.1.
Now given that we are merging from 4.0 to 4.1 - we might as well release from 4.1 instead of 4.0. Merging changes back from 4.1 to 4.0 just before release creates risk - as most of the testing was done in these 3 weeks period was done on 4.1.

Propose following changes

Patch version branches merged to major version branch.
Minor version has its own branch. Merge happens from last major to minor.