Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:45480
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 83.243.58.133 as permitted sender)
To: internals@lists.php.net
Content-Type: text/plain; charset="UTF-8"
Date: Fri, 04 Sep 2009 00:05:18 +0200
Message-ID: <1252015518.1733.104.camel@guybrush>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: 5.3.1 process
From: johannes@php.net (Johannes =?ISO-8859-1?Q?Schl=FCter?=)

Hi,

a new tool provides new opportunities and challenges, with the move to
svn I took some of the new possibilities and after many discussions
created a new release process which I'll try for 5.3.1 for which RC1 is
about to be packed. (having trouble accessing the snaps box to build
it...)

The very short story for most devs is to go on and work on the branches
as before (meaning trunk, PHP_5_3, PHP_5_2, commit at once etc.)

The longer story is this:

I've created a new branch PHP_5_3_1. This release branch receives
selective merges by the RM (me) only!

This branch will then be used to create RCs as often as needed
containing these fixes, as we won't have snaps for this branch only svn
checkouts and RCs will be available for testing. Therefore the aim is to
provide stable RCs and the only change between the last RC and the
stable release shall be the version number change.

Once 5.3.1 is to be published the PHP_5_3_1 branch will be converted
into a php_5_3_1 tag. (svn mv) And the 5.3.1 NEWS will be merged back
into PHP_5_3.

When committing to PHP_5_3 please be conservative till 5.3.1 is out to
ease merging and testing (we have no snaps for PHP_5_3_1) and try to
indicate whether you think the change should be merged or not and tell
me if you think I missed to merge a commit.

Once 5.3.1 is released this process will be reviewed and either be
documented or modified.

Hoping this works out,
johannes