Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:59493
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain managedit.ie designates 209.85.220.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <4F82878A.6030609@sugarcrm.com>
References: <4F82878A.6030609@sugarcrm.com>
Date: Mon, 9 Apr 2012 11:26:29 +0100
Message-ID: <CAGSj+Qv+r2674T=N7zC0DhC9Xy1+6FVLw7+MYusA9pwESHBZzQ@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=f46d042fd7147f3d9004bd3c7027
Subject: Re: [PHP-DEV] release process with git
From: kiall@managedit.ie (Kiall Mac Innes)

--f46d042fd7147f3d9004bd3c7027
Content-Type: text/plain; charset=ISO-8859-1

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
>
>

--f46d042fd7147f3d9004bd3c7027--