Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:61825
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.160.42 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <1343317268.1801.55.camel@guybrush>
References: <1343317268.1801.55.camel@guybrush>
Date: Thu, 26 Jul 2012 21:10:50 +0200
Message-ID: <CAEZPtU689QzWCt4t2X8h7PoYOTFoY+-6UBdwBVG=YnHNuhA7gQ@mail.gmail.com>
To: =?ISO-8859-1?Q?Johannes_Schl=FCter?= <johannes@schlueters.de>
Cc: PHP internals list <internals@lists.php.net>, Stas Malyshev <smalyshev@gmail.com>, 
	David Soria Parra <dsoria@gmx.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Release Frequency, NEWS, etc.
From: pierre.php@gmail.com (Pierre Joye)

hi Johannes,

On Thu, Jul 26, 2012 at 5:41 PM, Johannes Schl=FCter
<johannes@schlueters.de> wrote:
> Hi,
>
> since 5.4.0 was released on March 1st we had 6 releases for 5.3 and 5.4
> Basically following the mandate "At least one release per month, more at
> wish" from the release process RFC[1] with some additional "emergency"
> releases in between.
>
> The synchrony between those two means that currently 5.3 is nice 10
> releases ahead (5.3.15 and 5.4.5 were released together, 5.3.14 and
> 5.4.4 were etc.). This is nice as you can easily guess that a fix in
> 5.3.13 will be in 5.4.3, too.

And this is very (very) good for our users.

> Now such a fast, monthly cycle might be good for 5.4 but for 5.3 I think
> we should slow it down. In my opinion we should try to promote 5.4 over
> 5.3, give mit more exclusive visibility. People who stay on 5.3 expect
> to have a stable foundation, and aren't eager to check whether an update
> is relevant to them that often, especially as most (all?) things fixed
> in 5.3 are bugs which exist for a few years already. My expectation
> therefore is that users spend less attention on these and therefore miss
> critical fixes.

As far as I can tell, almost all releases had security related fixes
in them, 5.3 or 5.4. Given that, I do not see why we should slow down
anything as it will create more issues than what you would like to
solve.

> I would therefore like to reduce the 5.3 pace.

I won't.

> The current idea would be to skip every second release (unless security
> issues demand something else) both in release date as well as version
> number. So for instance 5.4.6 will be released sometime next month
> alone. A month later there will be 5.3.17 and 5.4.7.

Right, if there is no bug fix, there is no point to release. But if
there are fixes, then let release them at the same time, I see
absolutely no point to skip every 2nd release with 5.3 but to spare
time (which is not really an argument here :).

In short, either we support 5.3 with all kind of bug fixes or only
security fixes, or we don't support at all anymore. But some random
decision like that is only confusing and makes no sense.

There is that RFC that I would like to push to decide the EOL of 5.3,
let decide that instead :).

> Any comments on the general idea or suggestions for the NEWS thing?

NEWS is a big issue right now.

Last time I discussed that with David, we came to the point where we should=
:

- enforce the commit log format (see the git workflow,
https://wiki.php.net/vcs/gitworkflow#new_commit_message_format)
- create a script to generate NEWS based on the commit log
- if possible, enforce creation of bug # too for each
fix/feature/change, so it could be easily tracked

Cheers,
--
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org