On Wed, 1 Jun 2011, Internals wrote: > URL: https://wiki.php.net/rfc/releaseprocess
Comments again-they are mostly similar as before-I was quite annoyed that I didn't even get feedback on when I sent it last time: > ==== Example time line with two majors versions ==== > However it could happen that a new major version is desired while the > active major version is still heavily used. Like what we had between > php 4 and 5 or for the oldest, between php 3 and 4. Because of this, Perhaps the latest release before a new major one should run for a year longer. So in the example above, 5.6 runs until where 6.0 ends too. > <code> > **** pre release phase > ++++ release lifetime bugs > ---- release lifetime security only > D EOL > Version Time -> > 2011 2012 2013 2014 2015 2016 > 2017 > | | | | | | | | | | | | > | > 5.3 +++++++++++++-----D > 5.4 |*****+++++++++++++++++++++++++-----------D | | | | > | > 5.5 | | |******++++++++++++++++++++++++-----------D | | > | > 5.6 | | | |******++++++++++++++++++++++++-----------D > 6.0 | | |******++++++++++++++++++++++++-----------D | | > 6.1 | | | |******++++++++++++++++++++++++-----------D > </code> This variant is not workable, because there are (in the example) in 2014 *five* branches. Merging between those, manually and automatically is going to be a major pain. I'd say we all rather want to focus our time on fixes and new features; and not spend more time doing branch merging, whatever tool we use for this. I prefer the other one that was suggested before: > ==== Example time line with only one major version at a time ==== > <code> > **** pre release phase > ++++ release lifetime with all bugs fixes, no feature addition > ---- release lifetime security fixes only > D EOL > Version Time -> > 2011 2012 2013 2014 2015 2016 > 2017 > | | | | | | | | | | | | > | > 5.3 +++++++++++++-----D > 5.4 |*****+++++++++++++++++++++++++-----------D > 5.5 | | |******++++++++++++++++++++++++-----------D > 5.6 | | | | |******++++++++++++++++++++++++-----------D > 6.0 | | | | > |******++++++++++++++++++++++++-----------D > 6.1 | | | | > |******++++++++++++++++++++++++-----------D > </code> > ==== Timeline example for a release ==== > > > * June > * Decisions which features or changes will be in the next release > * 1st release alpha (may have many alpha) > * At least one release per month, more at wish > * Septempber, RC phases, biweekly release > * each RC should go through the QA before being published > * usually2 days Uh? The whole RC phase is QA. I don't see why you need another QA 'period'. I would however want to say that packaging and bundling is done on Wednesday, with any release on Thursday (morning). The original idea was to not have just a Friday for people to upgrade before a weekend. I've always bundled/packages on Wednesday and released on Thursday, but I've seen that lately it's all done on Thursday, and sometimes even Thursday evening US time. > * 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". > ===== Feature selection and development ===== > > RFCs have been introduced two years ago and have been proven as being > an amazing way to avoid conflicts while providing a very good way to > propose new things to php.net. New features or additions to the core > should go through the RFC process. New big language features, I agree with. Small little self-contained extension functions do not need a full blown RFC process. Extension's maintainers should have the responsibilty for this. (I am not saying it wouldn't be good to have an RFC for some of those new additions though). > It has been done successfully (as > the process went well, but the features were not necessary accepted) > already for a dozen of new features or improvements. 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?" > 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. > 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. I've nothing to hide, and I hope nobody else has either. Voting just on a wiki is too hidden as well- I think it should happen on the mailinglist with just +1, 0 and -1 responses. I quite like the Apache model: http://www.apache.org/foundation/voting.html and wouldn't mind adopting that in a slightly modified way. It is important however that votes come without comments. > ===== Feature(s) preview release, solving the experimental features ===== > > Some features require a lot of testing or users feedback before they > can be considered as ready, stable enough or proven as having made > good design decisions. Having them in normal releases is dangerous. > The past releases told us more that once than many good ideas ended as > being not so good after all. But we had to keep them in and, even > worst, maintain them forever. > > A feature preview release could solve this problem. A feature(s) > preview release gives us and our users a way to try bleeding edge > additions to the language or core while providing us with an > invaluable feedback to actually valid both the implementation and the > design choices. > Non core features (engine, stream, etc.) could benefit from a feature > preview release while doing it via PECL should be the preferred way. > > Feature(s) preview releases can happen any time and can be platform > specific. Whether a specific development branch is used or not is up > to the developers of the given features (external repositories like > github or bitbucket can obviously be used as well). Isn't a feature preview just a snapshot or (the first) alpha? I don't want to see various feature releases that don't have just trunk. The reason being mostly is that we would want to avoid splintering of "what is PHP"? Even more, because if we say "feature release" people might actually start using that to write applications against. I also don't see with being platform specific has to do with this. PHP is PHP, and on each platform PHP is (or at least should be) behaving the same. That also brings me to the point that all our downloads should be in one place: http://snaps.php.net for snapshots, and http://php.net/releases/index.php for releases. It makes no sense to have them spread over multiple locations. cheers, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
