hi Johannes, On Thu, Jul 26, 2012 at 5:41 PM, Johannes Schlüter <johan...@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
