You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Erik de Bruin <er...@ixsoftware.nl> on 2014/12/02 14:59:50 UTC
[LESS-RC] fix on develop or release branch?
Hi,
Fred brought up an interesting point in the other thread: should fixes
during the release phase be made on 'develop' and then merged into
'release', or the other way around?
This article [1] talks about deciding which features to include in a
release, and it leans towards merging from 'develop' to 'release'.
Which, for new features, makes sense. On the other hand, there is this
article [2] talks about fixes, which it suggests should be made on
'release' and merged into 'develop' right away.
As the RM for this release I tend to lean towards NOT adding features
to the 'release' branch after it has been cut, and to commit bug fixes
to the 'release' branch.
Thoughts?
EdB
1: http://producingoss.com/en/stabilizing-a-release.html
2: http://nvie.com/posts/a-successful-git-branching-model/
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [LESS-RC] fix on develop or release branch?
Posted by Chris Martin <wi...@gmail.com>.
Erik,
> As the RM for this release I tend to lean towards NOT adding features
> to the 'release' branch after it has been cut, and to commit bug fixes
> to the 'release' branch.
I follow this same model myself. The 'release' branch is considered
untouchable for the most part during a RC period, only taking critical bug
fixes deemed as blockers. Anything else is considered a known issue to be
addressed in a later build. Immediately following a critical bug fix in the
release branch, I immediately merge it back into develop to clear the bug
also for my testers and anyone who may be working on a new feature in
develop.
So I for one lean towards that method.
Chris
On Tue, Dec 2, 2014 at 9:50 AM, Tom Chiverton <tc...@extravision.com> wrote:
> On 02/12/14 13:59, Erik de Bruin wrote:
>
>> As the RM for this release I tend to lean towards NOT adding features
>> to the 'release' branch after it has been cut, and to commit bug fixes
>> to the 'release' branch.
>>
> This.
> By cutting off the release branch, you are stating the features in that
> release. Bug fixes only at that point, surely ?
>
> Tom
>
Re: [LESS-RC] fix on develop or release branch?
Posted by Tom Chiverton <tc...@extravision.com>.
On 02/12/14 13:59, Erik de Bruin wrote:
> As the RM for this release I tend to lean towards NOT adding features
> to the 'release' branch after it has been cut, and to commit bug fixes
> to the 'release' branch.
This.
By cutting off the release branch, you are stating the features in that
release. Bug fixes only at that point, surely ?
Tom
Re: [LESS-RC] fix on develop or release branch?
Posted by Alex Harui <ah...@adobe.com>.
I read [1]. IMO, it is discussing a different topic. In fact, the
previous chapter [3] is about release branches and talks about making
fixes in the release branch.
My takeaway is that [1] is about deciding what changes that have occurred
in the develop branch since the last release should go into the release
branch when it is time to create the release branch. IMO, this is not
currently a problem for Flex. We should just take everything. I suppose
someday something in the develop branch could be so risky that we have
second thoughts, but I’d say we shouldn't discuss what to do until we have
an actual scenario.
-Alex
On 12/2/14, 5:59 AM, "erik@ixsoftware.nl" <er...@ixsoftware.nl> wrote:
>Hi,
>
>Fred brought up an interesting point in the other thread: should fixes
>during the release phase be made on 'develop' and then merged into
>'release', or the other way around?
>
>This article [1] talks about deciding which features to include in a
>release, and it leans towards merging from 'develop' to 'release'.
>Which, for new features, makes sense. On the other hand, there is this
>article [2] talks about fixes, which it suggests should be made on
>'release' and merged into 'develop' right away.
>
>As the RM for this release I tend to lean towards NOT adding features
>to the 'release' branch after it has been cut, and to commit bug fixes
>to the 'release' branch.
>
>Thoughts?
>
>EdB
>
>1: http://producingoss.com/en/stabilizing-a-release.html
>2: http://nvie.com/posts/a-successful-git-branching-model/
[3] http://producingoss.com/en/release-branches.html
Re: [LESS-RC] fix on develop or release branch?
Posted by Erik de Bruin <er...@ixsoftware.nl>.
Well, the wiki basically already says this.
Fred brought up an alternative, which I thought we should discuss, but
since nearly everyone agrees with the existing approach, I think the
Wiki is fine as is.
Thanks,
EdB
On Tue, Dec 2, 2014 at 6:46 PM, Mihai Chira <mi...@gmail.com> wrote:
> Shall we make a wiki note of the decision?
>
> On 2 December 2014 at 17:45, Erik de Bruin <er...@ixsoftware.nl> wrote:
>> Seems like a clear consensus to me: all features in 'develop' go into
>> 'release', where we fix and merge back into 'develop'.
>>
>> Thanks everyone: nice, concise thread, clear resolution. I'm lovin' it ;-)
>>
>> EdB
>>
>>
>>
>> On Tue, Dec 2, 2014 at 6:21 PM, Kessler CTR Mark J
>> <ma...@usmc.mil> wrote:
>>> I'm for freezing new additions to the release branch once its created. Allow bug fixes to be applied to the release branch until an RC is cut. Merge the successful fixes back to the development branch
>>>
>>>
>>>
>>> -Mark
>>>
>>> -----Original Message-----
>>> From: Erik de Bruin [mailto:erik@ixsoftware.nl]
>>> Sent: Tuesday, December 02, 2014 9:00 AM
>>> To: dev@flex.apache.org
>>> Subject: [LESS-RC] fix on develop or release branch?
>>>
>>> Hi,
>>>
>>> Fred brought up an interesting point in the other thread: should fixes
>>> during the release phase be made on 'develop' and then merged into
>>> 'release', or the other way around?
>>>
>>> This article [1] talks about deciding which features to include in a
>>> release, and it leans towards merging from 'develop' to 'release'.
>>> Which, for new features, makes sense. On the other hand, there is this
>>> article [2] talks about fixes, which it suggests should be made on
>>> 'release' and merged into 'develop' right away.
>>>
>>> As the RM for this release I tend to lean towards NOT adding features
>>> to the 'release' branch after it has been cut, and to commit bug fixes
>>> to the 'release' branch.
>>>
>>> Thoughts?
>>>
>>> EdB
>>>
>>> 1: http://producingoss.com/en/stabilizing-a-release.html
>>> 2: http://nvie.com/posts/a-successful-git-branching-model/
>>>
>>>
>>>
>>> --
>>> Ix Multimedia Software
>>>
>>> Jan Luykenstraat 27
>>> 3521 VB Utrecht
>>>
>>> T. 06-51952295
>>> I. www.ixsoftware.nl
>>
>>
>>
>> --
>> Ix Multimedia Software
>>
>> Jan Luykenstraat 27
>> 3521 VB Utrecht
>>
>> T. 06-51952295
>> I. www.ixsoftware.nl
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [LESS-RC] fix on develop or release branch?
Posted by Mihai Chira <mi...@gmail.com>.
Shall we make a wiki note of the decision?
On 2 December 2014 at 17:45, Erik de Bruin <er...@ixsoftware.nl> wrote:
> Seems like a clear consensus to me: all features in 'develop' go into
> 'release', where we fix and merge back into 'develop'.
>
> Thanks everyone: nice, concise thread, clear resolution. I'm lovin' it ;-)
>
> EdB
>
>
>
> On Tue, Dec 2, 2014 at 6:21 PM, Kessler CTR Mark J
> <ma...@usmc.mil> wrote:
>> I'm for freezing new additions to the release branch once its created. Allow bug fixes to be applied to the release branch until an RC is cut. Merge the successful fixes back to the development branch
>>
>>
>>
>> -Mark
>>
>> -----Original Message-----
>> From: Erik de Bruin [mailto:erik@ixsoftware.nl]
>> Sent: Tuesday, December 02, 2014 9:00 AM
>> To: dev@flex.apache.org
>> Subject: [LESS-RC] fix on develop or release branch?
>>
>> Hi,
>>
>> Fred brought up an interesting point in the other thread: should fixes
>> during the release phase be made on 'develop' and then merged into
>> 'release', or the other way around?
>>
>> This article [1] talks about deciding which features to include in a
>> release, and it leans towards merging from 'develop' to 'release'.
>> Which, for new features, makes sense. On the other hand, there is this
>> article [2] talks about fixes, which it suggests should be made on
>> 'release' and merged into 'develop' right away.
>>
>> As the RM for this release I tend to lean towards NOT adding features
>> to the 'release' branch after it has been cut, and to commit bug fixes
>> to the 'release' branch.
>>
>> Thoughts?
>>
>> EdB
>>
>> 1: http://producingoss.com/en/stabilizing-a-release.html
>> 2: http://nvie.com/posts/a-successful-git-branching-model/
>>
>>
>>
>> --
>> Ix Multimedia Software
>>
>> Jan Luykenstraat 27
>> 3521 VB Utrecht
>>
>> T. 06-51952295
>> I. www.ixsoftware.nl
>
>
>
> --
> Ix Multimedia Software
>
> Jan Luykenstraat 27
> 3521 VB Utrecht
>
> T. 06-51952295
> I. www.ixsoftware.nl
Re: [LESS-RC] fix on develop or release branch?
Posted by Erik de Bruin <er...@ixsoftware.nl>.
Seems like a clear consensus to me: all features in 'develop' go into
'release', where we fix and merge back into 'develop'.
Thanks everyone: nice, concise thread, clear resolution. I'm lovin' it ;-)
EdB
On Tue, Dec 2, 2014 at 6:21 PM, Kessler CTR Mark J
<ma...@usmc.mil> wrote:
> I'm for freezing new additions to the release branch once its created. Allow bug fixes to be applied to the release branch until an RC is cut. Merge the successful fixes back to the development branch
>
>
>
> -Mark
>
> -----Original Message-----
> From: Erik de Bruin [mailto:erik@ixsoftware.nl]
> Sent: Tuesday, December 02, 2014 9:00 AM
> To: dev@flex.apache.org
> Subject: [LESS-RC] fix on develop or release branch?
>
> Hi,
>
> Fred brought up an interesting point in the other thread: should fixes
> during the release phase be made on 'develop' and then merged into
> 'release', or the other way around?
>
> This article [1] talks about deciding which features to include in a
> release, and it leans towards merging from 'develop' to 'release'.
> Which, for new features, makes sense. On the other hand, there is this
> article [2] talks about fixes, which it suggests should be made on
> 'release' and merged into 'develop' right away.
>
> As the RM for this release I tend to lean towards NOT adding features
> to the 'release' branch after it has been cut, and to commit bug fixes
> to the 'release' branch.
>
> Thoughts?
>
> EdB
>
> 1: http://producingoss.com/en/stabilizing-a-release.html
> 2: http://nvie.com/posts/a-successful-git-branching-model/
>
>
>
> --
> Ix Multimedia Software
>
> Jan Luykenstraat 27
> 3521 VB Utrecht
>
> T. 06-51952295
> I. www.ixsoftware.nl
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
RE: [LESS-RC] fix on develop or release branch?
Posted by Kessler CTR Mark J <ma...@usmc.mil>.
I'm for freezing new additions to the release branch once its created. Allow bug fixes to be applied to the release branch until an RC is cut. Merge the successful fixes back to the development branch
-Mark
-----Original Message-----
From: Erik de Bruin [mailto:erik@ixsoftware.nl]
Sent: Tuesday, December 02, 2014 9:00 AM
To: dev@flex.apache.org
Subject: [LESS-RC] fix on develop or release branch?
Hi,
Fred brought up an interesting point in the other thread: should fixes
during the release phase be made on 'develop' and then merged into
'release', or the other way around?
This article [1] talks about deciding which features to include in a
release, and it leans towards merging from 'develop' to 'release'.
Which, for new features, makes sense. On the other hand, there is this
article [2] talks about fixes, which it suggests should be made on
'release' and merged into 'develop' right away.
As the RM for this release I tend to lean towards NOT adding features
to the 'release' branch after it has been cut, and to commit bug fixes
to the 'release' branch.
Thoughts?
EdB
1: http://producingoss.com/en/stabilizing-a-release.html
2: http://nvie.com/posts/a-successful-git-branching-model/
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl