Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:59553
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.54 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAGSj+Qv+r2674T=N7zC0DhC9Xy1+6FVLw7+MYusA9pwESHBZzQ@mail.gmail.com>
References: <4F82878A.6030609@sugarcrm.com>
	<CAGSj+Qv+r2674T=N7zC0DhC9Xy1+6FVLw7+MYusA9pwESHBZzQ@mail.gmail.com>
Date: Mon, 9 Apr 2012 13:54:55 -0700
Message-ID: <CAKOpQSxMTUykqL1pBsfVWsYZ3rTZi7gOsrbk1yKk8ywSUbf1SA@mail.gmail.com>
To: Kiall Mac Innes <kiall@managedit.ie>
Cc: Stas Malyshev <smalyshev@sugarcrm.com>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=f46d04182638f02de904bd4537b9
Subject: Re: [PHP-DEV] release process with git
From: kris.craig@gmail.com (Kris Craig)

--f46d04182638f02de904bd4537b9
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Apr 9, 2012 at 3:26 AM, Kiall Mac Innes <kiall@managedit.ie> wrote:

> 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" <smalyshev@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
> >
> >
>

Yeah this also sounds similar to Gitflow, as this would basically be our
version of a "Release-x.xx" branch.  I would suggest allowing commits on
that branch, but *only* if they're bugfixes or minor housekeeping.  Each
commit would basically be the equivalent of a release candidate (i.e.
initial branch commit would be RC1, next commit RC2, etc).

Then when it's time to pull the trigger, the final commit on that branch
will be the actual release.  Then merge that branch back into PHP-5.4.  By
doing that last step, parallel ongoing development on the next 5.4 release
can continue without restriction.  Any last-minute bugfixes from the
PHP-5.4.X branch would be merged-in so everything would remain up-to-date.

--Kris

--f46d04182638f02de904bd4537b9--