Shall we make a wiki note of the decision?
On 2 December 2014 at 17:45, Erik de Bruin <e...@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 > <mark.kessler....@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:e...@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
