Looks good. Dont anticipate any issues at this time. Regards Srikanth Sundarrajan
> Date: Wed, 12 Nov 2014 20:48:37 +0530 > Subject: Re: Branching and versioning in Lens > From: [email protected] > To: [email protected] > > 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 > >> > >
