This is a very similar process to what OpenStack uses, it seems to work well for them.
They have a few guys on freenode in #openstack-infra that have shown themselves more than willing to go into detail about their setup and its pro/con's.. It would be worth asking them for their experience... Thanks, Kiall Sent from my phone. On Apr 9, 2012 7:54 a.m., "Stas Malyshev" <smalys...@sugarcrm.com> wrote: > Hi! > > 5.4.1 will be the first release we're releasing using our new git setup. > I would like to refine a process that we used to have for releases and > make small tweaks hopefully to allow us more predictable release > schedule and faster releases. > What I am proposing is the following: > 1. At the start of the cycle, PHP-5.4.X is branched off PHP-5.4. This is > done on Monday/Tuesday (days can be tweaked back&forth a bit, but I > assume we'll usually release on Thursday and count back from that). > 2. This branch is checked by RM to compile, pass unit tests > satisfactory, etc. and is released as 5.4.X RC1 > 3. In two weeks, if no critical errors is found in RC1, the same branch > is released as 5.4.X. If any critical errors are found, RM cherry-pick > fixes from 5.4 and release RC2 (RC3, etc. as needed) each two weeks > after no criticial bugs are in 5.4.X branch. > 4. In two more weeks, 5.4.(X+1) starts, provided we have changes from > 5.4.X. If not, it is postponed by 2 weeks. > > It is somewhat different from what we did before as we never disallow > committing into 5.4 and never allow (direct) committing into 5.4.X. This > also means we will be releasing 2-weeks-old code (or maybe older), i.e. > we will frequently be releasing code which has known (and fixed in other > branch) bugs. > > This will also mean we will have to define what constitutes critical > error, and maybe raise the bar a bit. I would like to propose the > following criteria for critical error: > 1. Compilation failure on a major platform (Linux, Windows, Mac, maybe > some others at RM discretion) > 2. Remotely exploitable security problem > 3. Bug that breaks a large piece of widely used functionality, effective > rendering it unusable (i.e. if somebody broke fopen() and it always > returned false). > Other things may be added on case-by-case basis but this will be the > guidelines. All other changes go into the next release. > > I think doing it this way will allow us to have 5.4.X releases monthly > as we planned in the release RFC. This will also mean that there would > be almost constant lag between committing regular fix and releasing it, > which may be larger than we had before. I think it won't be too bad if > we had regular monthly releases. > > Comments? > -- > Stanislav Malyshev, Software Architect > SugarCRM: http://www.sugarcrm.com/ > (408)454-6900 ext. 227 > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
