Branching strategy (was Re: [jira] Updated: (WOOKIE-142) Twitter API Widget)

[Ross Gardler <rg...@apache.org>]

On 11/10/2010 04:06, Scott Wilson wrote:
> (Maybe we need another discussion around branching strategy - e.g. do
> we have different branches for release versions (e.g. a 0.9.0 branch
> and a 0.9.1. branch), or do we keep on having the current code in
> trunk and just do potentially-disruptive feature development in
> branches?)

There are many ways of doing this. The way I personally prefer (but 
never insist upon, others should suggest alternatives) is:

- at code freeze for a release create a branch in which the release will 
be built (this allows development to continue in trunk even while 
release build and testing is underway)

- once the release is approved and built tag trunk as 0.9.0 or whatever

- use the branch for maintenance of the release (i.e. security fixes 
that can't wait for the next release from trunk)

Creating branches for disruptive features is important to allow people 
to continue to develop in trunk. However, they should only be created 
when really necessary as it can be difficult to maintain a branch.

Whatever policy is adopted needs to be documented in the relase 
management documents I hope Kris will put together as he works through 
this process.

Ross

Re: Branching strategy (was Re: [jira] Updated: (WOOKIE-142) Twitter API Widget)

[Ross Gardler <rg...@apache.org>]

On 12/10/2010 01:43, Kris Popat wrote:
>
> On 11 Oct 2010, at 21:22, Scott Wilson wrote:
>
>>
>> On 11 Oct 2010, at 18:06, Luciano Resende wrote:
>>
>>> On Mon, Oct 11, 2010 at 10:01 AM, Ross Gardler <rg...@apache.org>
>>> wrote:
>>>> On 11/10/2010 04:06, Scott Wilson wrote:
>>>>>
>>>>> (Maybe we need another discussion around branching strategy - e.g. do
>>>>> we have different branches for release versions (e.g. a 0.9.0 branch
>>>>> and a 0.9.1. branch), or do we keep on having the current code in
>>>>> trunk and just do potentially-disruptive feature development in
>>>>> branches?)
>>>>
>>>> There are many ways of doing this. The way I personally prefer (but
>>>> never
>>>> insist upon, others should suggest alternatives) is:
>>>>
>>>> - at code freeze for a release create a branch in which the release
>>>> will be
>>>> built (this allows development to continue in trunk even while
>>>> release build
>>>> and testing is underway)
>>>>
>>>> - once the release is approved and built tag trunk as 0.9.0 or whatever
>>>>
>>>> - use the branch for maintenance of the release (i.e. security fixes
>>>> that
>>>> can't wait for the next release from trunk)
>>>>
>>>
>>> +1, this makes it easy to have maintenance release (e.g 0.9.1, 0.9.2,
>>> etc). I'd just mention that, for the maintenance release it's probably
>>> enough to just have a tag created and continue to use the same branch
>>> (e.g 0.9.0)
>>
>> +1 also. I was thinking about how we might start work on the oAuth
>> integration and other new features while still being able to make
>> maintenance releases of 0.9.0 if there are critical bugs found. I
>> think that answers it nicely.
>>
>
> +1 yes, I was thinking this myself, the only issue that we might need to
> be aware of is if testing of the release package comes up with some
> issues that need to be fixed then we also need to remember to merge
> those fixes back into truck.

Yes, that's the "downside" of branching rather than doing a code freeze. 
In a small community like this a code freeze for a short period is 
usually not a major problem. However, as the community grows the 
overhead of managing the branch and trunk is worthwhile and has to be 
done anyway for emergency maintenance releases of the branch.

Ross

Re: Branching strategy (was Re: [jira] Updated: (WOOKIE-142) Twitter API Widget)

[Ross Gardler <rg...@apache.org>]

On 21/10/2010 09:20, Thomas Ernest wrote:
> Hi,
>
> On 10/12/2010 10:43 AM, Kris Popat wrote:
>>

...

>>>> On Mon, Oct 11, 2010 at 10:01 AM, Ross Gardler<rg...@apache.org>
>>>> wrote:

...

>>>>> - once the release is approved and built tag trunk as 0.9.0 or
>>>>> whatever
> My question will probably sounds stupid, but I would like to understand.
> Why do we make a tag from trunk and not from the branch ?
> Besides, where will be committed changes between branch creation and tag
> build : trunk, branch, branch then trunk or trunk then branch ? I mean
> there are several cases : bug fix in trunk, bug fix in branch and
> probably some other ones ?

That's not a stupid question, it's a very sensible one. It highlights an 
error in the proposed process, we should indeed be tagging from the branch.

So:

branch for the release

test and fix bugs in the branch (merging them with trunk)

continue development in trunk (but don't merge anything other than bug 
fixes to branch - and only using a review then commit process)

tag from branch (not trunk as we originally agreed)

Ross

Re: Branching strategy (was Re: [jira] Updated: (WOOKIE-142) Twitter API Widget)

[Thomas Ernest <th...@gmail.com>]

Hi,

On 10/12/2010 10:43 AM, Kris Popat wrote:
>
> On 11 Oct 2010, at 21:22, Scott Wilson wrote:
>
>>
>> On 11 Oct 2010, at 18:06, Luciano Resende wrote:
>>
>>> On Mon, Oct 11, 2010 at 10:01 AM, Ross Gardler <rg...@apache.org>
>>> wrote:
>>>> On 11/10/2010 04:06, Scott Wilson wrote:
>>>>>
>>>>> (Maybe we need another discussion around branching strategy - e.g. do
>>>>> we have different branches for release versions (e.g. a 0.9.0 branch
>>>>> and a 0.9.1. branch), or do we keep on having the current code in
>>>>> trunk and just do potentially-disruptive feature development in
>>>>> branches?)
>>>>
>>>> There are many ways of doing this. The way I personally prefer (but
>>>> never
>>>> insist upon, others should suggest alternatives) is:
>>>>
>>>> - at code freeze for a release create a branch in which the release
>>>> will be
>>>> built (this allows development to continue in trunk even while
>>>> release build
>>>> and testing is underway)
>>>>
>>>> - once the release is approved and built tag trunk as 0.9.0 or
>>>> whatever
My question will probably sounds stupid, but I would like to understand.
Why do we make a tag from trunk and not from the branch ?
Besides, where will be committed changes between branch creation and tag
build : trunk, branch, branch then trunk or trunk then branch ? I mean
there are several cases : bug fix in trunk, bug fix in branch and
probably some other ones ?
>>>>
>>>> - use the branch for maintenance of the release (i.e. security
>>>> fixes that
>>>> can't wait for the next release from trunk)
>>>>
>>>
>>> +1, this makes it easy to have maintenance release (e.g 0.9.1, 0.9.2,
>>> etc). I'd just mention that, for the maintenance release it's probably
>>> enough to just have a tag created and continue to use the same branch
>>> (e.g 0.9.0)
>>
>> +1 also. I was thinking about how we might start work on the oAuth
>> integration and other new features while still being able to make
>> maintenance releases of 0.9.0 if there are critical bugs found. I
>> think that answers it nicely.
>>
>
> +1 yes, I was thinking this myself, the only issue that we might need
> to be aware of is if testing of the release package comes up with some
> issues that need to be fixed then we also need to remember to merge
> those fixes back into truck.
>
>
>>>> Creating branches for disruptive features is important to allow
>>>> people to
>>>> continue to develop in trunk. However, they should only be created
>>>> when
>>>> really necessary as it can be difficult to maintain a branch.
>>>>
>>>
>>> +1, and they should be merged back as soon as they are stable and
>>> people agree with it.
>>
>> +1 It was good to work with Randy on the JPA/JCR stuff in a branch
>> for this purpose, but it was a lot of overhead to keep it in sync
>> with trunk, so I'd definitely prefer to only do this for major
>> replumbing.
>>
>
> +1
+1 I got this one, no need for explanation ;-)
>>>> Whatever policy is adopted needs to be documented in the relase
>>>> management
>>>> documents I hope Kris will put together as he works through this
>>>> process.
>>>>
>>>
>>> +1
>> +1
>
> +1 Yes am working on some initial release management documents at the
> moment on the wiki, will post later when they are up
+1 Thank you for documenting all of that.

Thomas.

Re: Branching strategy (was Re: [jira] Updated: (WOOKIE-142) Twitter API Widget)

[Kris Popat <kj...@gmail.com>]

On 11 Oct 2010, at 21:22, Scott Wilson wrote:

>
> On 11 Oct 2010, at 18:06, Luciano Resende wrote:
>
>> On Mon, Oct 11, 2010 at 10:01 AM, Ross Gardler  
>> <rg...@apache.org> wrote:
>>> On 11/10/2010 04:06, Scott Wilson wrote:
>>>>
>>>> (Maybe we need another discussion around branching strategy -  
>>>> e.g. do
>>>> we have different branches for release versions (e.g. a 0.9.0  
>>>> branch
>>>> and a 0.9.1. branch), or do we keep on having the current code in
>>>> trunk and just do potentially-disruptive feature development in
>>>> branches?)
>>>
>>> There are many ways of doing this. The way I personally prefer  
>>> (but never
>>> insist upon, others should suggest alternatives) is:
>>>
>>> - at code freeze for a release create a branch in which the  
>>> release will be
>>> built (this allows development to continue in trunk even while  
>>> release build
>>> and testing is underway)
>>>
>>> - once the release is approved and built tag trunk as 0.9.0 or  
>>> whatever
>>>
>>> - use the branch for maintenance of the release (i.e. security  
>>> fixes that
>>> can't wait for the next release from trunk)
>>>
>>
>> +1, this makes it easy to have maintenance release (e.g 0.9.1, 0.9.2,
>> etc). I'd just mention that, for the maintenance release it's  
>> probably
>> enough to just have a tag created and continue to use the same branch
>> (e.g 0.9.0)
>
> +1 also. I was thinking about how we might start work on the oAuth  
> integration and other new features while still being able to make  
> maintenance releases of 0.9.0 if there are critical bugs found. I  
> think that answers it nicely.
>

+1 yes, I was thinking this myself, the only issue that we might need  
to be aware of is if testing of the release package comes up with some  
issues that need to be fixed then we also need to remember to merge  
those fixes back into truck.


>>> Creating branches for disruptive features is important to allow  
>>> people to
>>> continue to develop in trunk. However, they should only be created  
>>> when
>>> really necessary as it can be difficult to maintain a branch.
>>>
>>
>> +1, and they should be merged back as soon as they are stable and
>> people agree with it.
>
> +1 It was good to work with Randy on the JPA/JCR stuff in a branch  
> for this purpose, but it was a lot of overhead to keep it in sync  
> with trunk, so I'd definitely prefer to only do this for major  
> replumbing.
>

+1
>>> Whatever policy is adopted needs to be documented in the relase  
>>> management
>>> documents I hope Kris will put together as he works through this  
>>> process.
>>>
>>
>> +1
> +1

+1 Yes am working on some initial release management documents at the  
moment on the wiki, will post later when they are up

>>
>>
>> -- 
>> Luciano Resende
>> http://people.apache.org/~lresende
>> http://twitter.com/lresende1975
>> http://lresende.blogspot.com/
>

Re: Branching strategy (was Re: [jira] Updated: (WOOKIE-142) Twitter API Widget)

[Scott Wilson <sc...@gmail.com>]

On 11 Oct 2010, at 18:06, Luciano Resende wrote:

> On Mon, Oct 11, 2010 at 10:01 AM, Ross Gardler <rg...@apache.org> wrote:
>> On 11/10/2010 04:06, Scott Wilson wrote:
>>> 
>>> (Maybe we need another discussion around branching strategy - e.g. do
>>> we have different branches for release versions (e.g. a 0.9.0 branch
>>> and a 0.9.1. branch), or do we keep on having the current code in
>>> trunk and just do potentially-disruptive feature development in
>>> branches?)
>> 
>> There are many ways of doing this. The way I personally prefer (but never
>> insist upon, others should suggest alternatives) is:
>> 
>> - at code freeze for a release create a branch in which the release will be
>> built (this allows development to continue in trunk even while release build
>> and testing is underway)
>> 
>> - once the release is approved and built tag trunk as 0.9.0 or whatever
>> 
>> - use the branch for maintenance of the release (i.e. security fixes that
>> can't wait for the next release from trunk)
>> 
> 
> +1, this makes it easy to have maintenance release (e.g 0.9.1, 0.9.2,
> etc). I'd just mention that, for the maintenance release it's probably
> enough to just have a tag created and continue to use the same branch
> (e.g 0.9.0)

+1 also. I was thinking about how we might start work on the oAuth integration and other new features while still being able to make maintenance releases of 0.9.0 if there are critical bugs found. I think that answers it nicely.

>> Creating branches for disruptive features is important to allow people to
>> continue to develop in trunk. However, they should only be created when
>> really necessary as it can be difficult to maintain a branch.
>> 
> 
> +1, and they should be merged back as soon as they are stable and
> people agree with it.

+1 It was good to work with Randy on the JPA/JCR stuff in a branch for this purpose, but it was a lot of overhead to keep it in sync with trunk, so I'd definitely prefer to only do this for major replumbing.

>> Whatever policy is adopted needs to be documented in the relase management
>> documents I hope Kris will put together as he works through this process.
>> 
> 
> +1
+1
> 
> 
> -- 
> Luciano Resende
> http://people.apache.org/~lresende
> http://twitter.com/lresende1975
> http://lresende.blogspot.com/

Re: Branching strategy (was Re: [jira] Updated: (WOOKIE-142) Twitter API Widget)

[Luciano Resende <lu...@gmail.com>]

On Mon, Oct 11, 2010 at 10:01 AM, Ross Gardler <rg...@apache.org> wrote:
> On 11/10/2010 04:06, Scott Wilson wrote:
>>
>> (Maybe we need another discussion around branching strategy - e.g. do
>> we have different branches for release versions (e.g. a 0.9.0 branch
>> and a 0.9.1. branch), or do we keep on having the current code in
>> trunk and just do potentially-disruptive feature development in
>> branches?)
>
> There are many ways of doing this. The way I personally prefer (but never
> insist upon, others should suggest alternatives) is:
>
> - at code freeze for a release create a branch in which the release will be
> built (this allows development to continue in trunk even while release build
> and testing is underway)
>
> - once the release is approved and built tag trunk as 0.9.0 or whatever
>
> - use the branch for maintenance of the release (i.e. security fixes that
> can't wait for the next release from trunk)
>

+1, this makes it easy to have maintenance release (e.g 0.9.1, 0.9.2,
etc). I'd just mention that, for the maintenance release it's probably
enough to just have a tag created and continue to use the same branch
(e.g 0.9.0)

> Creating branches for disruptive features is important to allow people to
> continue to develop in trunk. However, they should only be created when
> really necessary as it can be difficult to maintain a branch.
>

+1, and they should be merged back as soon as they are stable and
people agree with it.

> Whatever policy is adopted needs to be documented in the relase management
> documents I hope Kris will put together as he works through this process.
>

+1


-- 
Luciano Resende
http://people.apache.org/~lresende
http://twitter.com/lresende1975
http://lresende.blogspot.com/