>> * running the various test suites (phpt, custom real life tests, >> platform specific tests). Some tests need a day to run >> * November, Final >> * Last RC taken as final, golden release (no change between the last RC >> and the final version) > > TBH, I think 6 months is too much between first alpha and release. > Because we'd only have 6 months for a "normal cycle".
That's a max and reasonable time frame based on what we had in the past and based on discussions with the devs actually doing the work. So what if we make it before? a wonder! But at least there is a max deadline. > One issue with it though, the page that lists all the RFCs isn't > maintained, and status isn't always updated. That needs to be done > otherwise we get to "oh, is this implemented yet?" help welcomes. >> Features can use branch(es) if necessary, doing so will minimize the >> impact of other commits and changes on the development of a specific >> feature (or the other way 'round). The shorter release cycle also >> ensures that a given feature can get into the next release, as long as >> the RFC has been accepted. > > I would word "can use branches if necessary" stronger, like "can use > branches if *absolutely* necessary". The reason why, is that it is a good > idea to get as many people familiar with new code. Of course, if there > is a lot of ongoing work then a feature branch helps, but it should be > merged into trunk as soon as it compiles (and doesn't break any test > case) for peer review and more testing. do not see a reason to change this part, it is self explaining and if a developer likes to use an extra branche, then it is up to him as he maintains that code anyway, at least for the development period. >> The change to what we have now is the voting process. It will not >> happen anymore on the mailing list but in the RFCs directly, for >> php.net members, in an anonymous way (who votes what won't be made >> public). >> >> The question for this section is about who will be allowed to vote: >> * php-src (yes, no) >> * php-doc (yes, no) >> * qa, *phpt (yes, no) >> * other sub projects like pear (yes, no) >> >> NB: the poll plugin will be installed shortly > > A few things here that I don't like. First of all, I think voting > *should* be public. Please read the RFC. >> ===== Feature(s) preview release, solving the experimental features ===== > Isn't a feature preview just a snapshot or (the first) alpha? no, and it may not be ready in time for a given release. And that allows us to show something at any time to get more feedbacks from users about a given complex or big feature/change without taking the risk to break a given normal release. That sounds like a good solution and can be done at any time. -- 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
