You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lens.apache.org by "amareshwarisr ." <am...@gmail.com> on 2014/11/12 01:14:49 UTC
Branching and versioning in Lens
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
Re: Branching and versioning in Lens
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
It sounds good.
Regards
JB
On 11/12/2014 04:18 PM, amareshwarisr . wrote:
> 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, <jb...@nanthrax.net> 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
>>>
>>
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
RE: Branching and versioning in Lens
Posted by Srikanth Sundarrajan <sr...@hotmail.com>.
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: amareshwari@gmail.com
> To: dev@lens.incubator.apache.org
>
> 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, <jb...@nanthrax.net> 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
> >>
> >
Re: Branching and versioning in Lens
Posted by "amareshwarisr ." <am...@gmail.com>.
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, <jb...@nanthrax.net> 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
>>
>
Re: Branching and versioning in Lens
Posted by jb...@nanthrax.net.
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