On Friday, April 27, 2012 11:23:59 PM UTC+2, Mark Badolato wrote: > > On Fri, Apr 27, 2012 at 12:43 PM, Daniel A.Tiecher <[email protected]>wrote: > >> I share Kris's opinion. We have already dragged this release a lot and >> then postponing it to August would mean that a truck load of new PRs would >> be opened against master, which in turn would need to: >> >> a) be integrated in the 2.1 release and possibly hurt the stability of >> the codebase which could push the tentative date even further >> b) be left alone until we release 2.1 >> > > A branch could be created RELEASE_2_1 which is feature-frozen and only for > bug fixes and component stabilization towards the release. PR's for new > features etc would continue to be contributed to master. > When RELEASE_2_1 is ready, it gets tagged, release, and the work gets > merged back down into master. Conflict resolutions, compatibility issues > etc need to be resolved, but this is true of any scenario. > > Bugs affecting (necessary for) the release should be part of > the RELEASE_2_1 branch, but if they are sent as PRs to master, there's no > reason that it couldn't be cherry-picked for RELEASE_2_1, which makes sense > since it's a bug that affects the release. > > Further along in the development cycle, when it's feature-freeze time (or > other appropriate time) a RELEASE_2_2 branch would be created from master, > then lather, rinse, repeat. > > +1 for me create tag, delay release until form will stabilise and do not merge new features from the middle of June.
-- If you want to report a vulnerability issue on symfony, please send it to security at symfony-project.com You received this message because you are subscribed to the Google Groups "symfony developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en
