Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:3020 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 15479 invoked from network); 30 Jun 2003 07:08:16 -0000 Received: from unknown (HELO www.lerdorf.com) (66.93.78.119) by pb1.pair.com with SMTP; 30 Jun 2003 07:08:16 -0000 Received: from [10.0.1.13] (Dell [10.0.1.13]) by www.lerdorf.com (8.12.9/8.12.9/Debian-4) with ESMTP id h5U78GEa026962 for ; Mon, 30 Jun 2003 00:08:16 -0700 Date: Mon, 30 Jun 2003 00:08:16 -0700 (PDT) To: internals@lists.php.net Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Release Management and Versioning From: rasmus@lerdorf.com (Rasmus Lerdorf) We have taken some steps to clean up our release process, but let's nail it down completely to avoid arguments every time we release something. Can we agree on the following? All new development happens on HEAD. Snapshot and alpha releases are released right from the development branch with a TAG to mark when the release happened. To start the release process, we make a release branch. Say, PHP_5_3. Once we have branched for a release there should be no large features added. Missing functions here or there or other small things can go in. And anywhere along this release branch we can release betas to get more people to test. After a beta or two, when we are fairly confident we are ready to do the final QA we roll a release candidate. At this point we are in serious code freeze mode. Only bug fixes allowed at this point. Once released, the release branch is used for bug fixes only. So the PHP_5_3 branch which spawned PHP-5.3.0 is used to create PHP-5.3.1, PHP-5.3.2, etc. Each release is a TAG on that release branch. New development is back on the HEAD branch which is one and the same as the PHP_5 branch when we are dealing with the latest major version. New development, if necessary, on previous major releases happen on PHP_4, PHP_3, etc. branches. Some obvious things that fall out of this is that there can't be any backward compatibility breakage in a point release (meaning 3rd digit) unless it is directly fixing some serious breakage. There also cannot be any binary compatibility breakage in a point release. Any change that breaks binary compatibility automatically forces a new minor (2nd digit) version. I guess the sticky point here is what is a beta and what isn't. If we can't get agreement on the above explanation and we want to push "beta" back a step to mean a cvs snapshot without an associated release branch, fine, let's do that, but let's clearly define that this is what we are going to do in the future and once defined put this (or a similar) document up on php.net that defines this process for everyone. Or a README.Releases in the code. -Rasmus