Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:47873 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 44254 invoked from network); 11 Apr 2010 19:24:56 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 11 Apr 2010 19:24:56 -0000 Authentication-Results: pb1.pair.com smtp.mail=rasmus@lerdorf.com; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=rasmus@lerdorf.com; sender-id=unknown Received-SPF: error (pb1.pair.com: domain lerdorf.com from 209.85.160.170 cause and error) X-PHP-List-Original-Sender: rasmus@lerdorf.com X-Host-Fingerprint: 209.85.160.170 mail-gy0-f170.google.com Received: from [209.85.160.170] ([209.85.160.170:58810] helo=mail-gy0-f170.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id B0/C5-11452-70222CB4 for ; Sun, 11 Apr 2010 15:24:56 -0400 Received: by gyf2 with SMTP id 2so2489257gyf.29 for ; Sun, 11 Apr 2010 12:24:53 -0700 (PDT) Received: by 10.101.136.13 with SMTP id o13mr5040007ann.235.1271013892976; Sun, 11 Apr 2010 12:24:52 -0700 (PDT) Received: from [192.168.200.22] (c-98-234-184-167.hsd1.ca.comcast.net [98.234.184.167]) by mx.google.com with ESMTPS id 9sm914077ywe.37.2010.04.11.12.24.50 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 11 Apr 2010 12:24:51 -0700 (PDT) Message-ID: <4BC22201.4060909@lerdorf.com> Date: Sun, 11 Apr 2010 12:24:49 -0700 User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.10pre) Gecko/20100410 Shredder/3.0.5pre MIME-Version: 1.0 To: PHP Developers Mailing List X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Dev process confusion? From: rasmus@lerdorf.com (Rasmus Lerdorf) A few people, well ok, Lukas mainly, seem to be confused about our current process, or lack of it. I think it is pretty simple, and it is what we used for years. We commit all new code to trunk. Bug fixes should obviously be committed to any active branches they apply to as well. When we have enough new interesting code in trunk we branch and release from that. Sometimes there may be code in trunk that isn't quite ready. We then either fix it, or the RM can decide to still branch and then revert particular features from the new release branch. The idea here is to get things active in our development branch again. Feel free to commit minor things with little or no discussion. Make sure you include a test case and that your change doesn't break the build nor existing tests. You can always run a partial "make test" like this: make test TESTS=ext/soap to only run the SOAP tests, for example. Major changes/features should be discussed and probably RFC'ed, and if there is general agreement, or even indifference, commit away. If there are intelligent detractors, then try to work it out on the list. So, don't wait around for talk of the next release. Get your code into trunk as soon as possible so we have some time to work out issues. You committing your code to trunk should be what speeds up the next release, not the other way around. -Rasmus