Thanks Jean, but proposing some modifications on the branching after discussing with Srikanth and Sharad offline.
Here is how it looks now : * Branching Lens has two main branches - <master> and <current-release-line>. All the day to day development happens on <master> branch. <current-release-line> branch is used to make releases. When <master> branch is ready for release (all issues marked for release are fixed and all tests passing), <master> will be merged to <current-release-line> and release will be triggered from <current-release-line>. Once the release is done <current-release-line> will be merged back into <master> for version number upgrade and any other changes done on the release line. If a critical release (not pulling code from master) needs to be made, a new branch will be created with release number, by checking out <current-release-line> branch. And changes will be put on the branch. Once the branch is ready they will merged to <current-release-line> and released. The changes should be merged back into <master> from <current-release-line> once the release is made and resolving conflicts in <master> if any. There can feature branches created from <master>, if feature is not actively developed in <master> branch directly. Having two main branches makes all release tags to be created on <current-release-line> branch and removes the pile up of old and stale branches, which are created by one for each release. And merging of issues done by critical patch release is already taken care. For major version increments, <current-release-line> will be branched to a a <$major.x-line> and <current-release-line> and master will be moved to next major version. Your thoughts and suggestions are welcome Thanks Amareshwari On Wed, Nov 12, 2014 at 5:52 AM, <[email protected]> wrote: > Hi, > > it sounds good to me. > > The branching is a bit special compared to what I usually do, but I > understand the points (I have active branches where I can do release, it's > easier and it doesn't require merge). > > I agree for the versioning. > > Regards > JB > > > On 2014-11-12 01:14, amareshwarisr . wrote: > >> Hello all, >> >> Here is current strategy we are following for branching and versioning in >> Lens. If people are fine with the same in apache repo also, I'm planning >> to >> push both master and develop branches to the repo. >> >> * Branching >> >> Lens has two main branches - <master> and <develop>. All the day to day >> development happens on <develop> branch. <master> branch is used to make >> releases. When develop branch is ready for release (all issues marked for >> release are fixed and all tests passing), develop will merged to master >> and >> release will be triggered from master. Once the release is done master >> will >> be merged into develop for version number upgrade. >> >> If a critical release (not pulling code from develop) needs to be made, a >> new branch will be created with release number, by checking out master. >> And >> changes will be put on the branch. Once the branch is ready they will >> merged to master and released. The changes should be merged into develop >> from master once the release is made and resolving conflicts in develop if >> any. >> >> There can feature branches created, if feature is not actively developed >> in develop branch directly. >> >> Having two main branches makes all release tags to be created on master >> branch and removes the pile up old and stale branches, which are created >> by >> one for each release. And Merging of issues done by critical patch release >> is already taken care. >> >> >> * Versioning >> >> Lens follows three number versioning which is major.minor.revision. If >> the current release is 1.1.0, the next usual development release will be >> 1.2.0. If there needs to be separate release on released version and not >> from development branch (usually critical patch release), it will be >> 1.1.1. >> If the next release is not api compatible with previous release, then the >> major version needs to be incremented, then it would become 2.0.0. This >> way >> all 1.x.x releases will be compatible with one another. And >> incompatibility >> is clearly communicated to users through major version number change. >> >> Let me know your thoughts >> >> Thanks >> >> Amareshwari >> >
