On Thu, Mar 18, 2010 at 4:50 PM, Lukas Kahwe Smith <m...@pooteeweet.org>wrote:
> > On 18.03.2010, at 18:48, David Soria Parra <d...@php.net> wrote: > > On 2010-03-18, Pierre Joye <pierre....@gmail.com> wrote: >> >>> On Thu, Mar 18, 2010 at 6:16 PM, Derick Rethans <der...@php.net> wrote: >>> >>> I do agree that we need to do major releases more often, but just >>>> setting a time already feels wrong. It's still open source, so it's >>>> ready when it is ready. That of course should not mean that we should >>>> keep on adding features endlessly. >>>> >>> >>> for releases, avoid commits rushes right before the freeze, etc. As >>> I've been said before already, I'm all for a fixed release cycle, it >>> is then much easier to define clear priorities and roadmaps. >>> >> >> +1. i think having a fixed release cycle has nothing to do with >> being opensource or not but with being more predictable for people >> depending on release dates. >> > > right. and again i think i was quite explict in my original mail that > common sense still applies. if we have a buggy release we will obviously not > release it just because. as for having enough to actually warrant a release > i do not ever remember a time where there werent atleast a handful feasible > proposals in varying size on the table. > > regard > Lukas > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > +1 For shorter release cycles. Shorter release cycles could also allow us to move major releases immediately to bug and security fixes only. I've never been a fan of seeing additional features added in minor releases. It's confusing enough to try and keep track of features from one major release to the next, but then we add in features on minors as well. "That feature was added in 5.3.1". Obviously this was not a good option when major releases were at 12 months or more apart. If we can shorten the cycle, I think it might be a good idea to visit how quickly each release is frozen to bug and security fixes only. This may just be a developmental pet-peave of mine, I'm sure I'll hear about it soon if the idea is unfavorable. As an additional note to this, performance patches which don't add additional features but only increase speed would still be fair game. P.S. 2: Reduced release cycle times might reduce the burdens on RMs as well by allowing them to commit to shorter time periods of release management responsibility. Not that I hear any of them complaining, just thinking this might be another good reason to give it a try. Eric Lee Stewart
