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 <[email protected]> wrote:
> Shall we make a wiki note of the decision?
>
> On 2 December 2014 at 17:45, Erik de Bruin <[email protected]> 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
>> <[email protected]> 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:[email protected]]
>>> Sent: Tuesday, December 02, 2014 9:00 AM
>>> To: [email protected]
>>> 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

Reply via email to