# [RFC] Release Process - Thread: https://externals.io/message/50415 - Original archive: https://news-web.php.net/php.internals/50415 - Started by Felipe Pena on 2010-11-23T01:21:13+00:00 - Messages: 45 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/50415.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #50415 — Felipe Pena — 2010-11-23T01:21:13+00:00 URL: https://externals.io/message/50415#50415 Hi, With the recent chaos in the way we begin and ended releases, we would like to propose a clean way to deal with releases and related decisions: [1] PHP releases have always been done spontaneously, in a somehow chaotic way. Individual(s) decided when a release will happen and what could or could fit in. Release managers role are unclear and the way to nominate them is not clearly defined either. The goals of this RFC aim to solve these issues while giving to us, our users and 3rd parties (distributions, contributors, etc.) more visibility and the ability to actually have a roadmap, or plan developments. This RFC aims to define: * a clear release cycle, periodic * a transparent decision process for the feature additions, via the RFCs and a transparent but anonymous vote * which changes can be done during a release lifetime (BC breaks, bugs fixes, security fixes, etc.) * a transparent way to choose release managers for a given release * a better usage of bugs.php.net to track each change, addition, bug fixes (security incl.) or other various tasks related to a release * reduce time between bugs fix releases * reduce the time to get new features in a release * suppress BC breaks in bugs fix releases * feature(s) preview release [1] http://wiki.php.net/rfc/releaseprocess -- Regards, Felipe Pena --- ## #50420 — johannes@schlueters.de — 2010-11-23T09:31:59+00:00 URL: https://externals.io/message/50415#50420 · In reply to: #50415 Hi, > With the recent chaos in the way we begin and ended releases, we would > like to propose a clean way to deal with releases and related decisions: [1] Thanks for preparing this. I have one change proposal: With the proposed model it might, as you have illustrated, happen that there are 5 versions being maintained. As I mentioned multiple times on this list, on irc and other places I like a Ubuntu-like model with two kinds of release which I, for the purpose of this discussion, call "early access" (EA) and "long term supported" (LTS) version. At any given time only one EA may exist. When a new LTS version is being released the previous LTS version enters security-only mode to give users a transition period. Between every LTS version there are two EA versions. 2011 2012 2013 2014 2015 2016 2017 | | | | | | | | | | | | | LTS1 +++++++++++++++++++++++++++++++++++++-----------D | | | | EA1 | | ++++++++++++D | | | | | | | | EA2 | | | | ++++++++++++D | | | | | | LTS2 | | | | | | ++++++++++++++++++++++++++++++++++++-----------D EA3 | | | | | | | | ++++++++++++D EA4 | | | | | | | | | | ++++++++++++D The benefit is that developers and users who require a specific feature get it early while distributors/hosters/software vendors/... have a safe bet. johannes --- ## #50430 — Derick Rethans — 2010-11-23T10:07:05+00:00 URL: https://externals.io/message/50415#50430 · In reply to: #50415 > With the recent chaos in the way we begin and ended releases, we would > like to propose a clean way to deal with releases and related decisions: [1] Really? I think you're blowing this all way out of proportion. I don't mind a yearly release cycle, as we should get out more releases. I don't mind a monthly release cycle for .z releases. What however goes straight against this is: * January o Decisions which features or changes will be in the next release You don't decide on it, you just have to go with what we have. All the rest you write in the RFC is basically already as we do it. regards, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug --- ## #50437 — Ferenc Kovacs — 2010-11-23T11:32:29+00:00 URL: https://externals.io/message/50415#50437 · In reply to: #50430 > > > > […] > [1] > > Really? I think you're blowing this all way out of proportion. > Why do you think that? I can see two reason: 1) you think that the current rules/policies/methods are good enough. 2) you think that these rules/policies/methods aren't important for the quality of the release. both seems wrong from the past experiences of new php major/major.minor releases. see my last email in the other thread > > I don't mind a yearly release cycle, as we should get out more releases. > I don't mind a monthly release cycle for .z releases. > > What however goes straight against this is: > > * January > o Decisions which features or changes will be in the next > release > > You don't decide on it, you just have to go with what we have. > who decided that? > > All the rest you write in the RFC is basically already as we do it. > yeah, maybe, but they aren't written down, accepted and well-known rules, so you can forgot/misunderstand/bend them. :/ Tyrael --- ## #50443 — Derick Rethans — 2010-11-23T13:59:52+00:00 URL: https://externals.io/message/50415#50443 · In reply to: #50437 > > […] > > yeah, maybe, but they aren't written down, accepted and well-known rules, so > you can forgot/misunderstand/bend them. :/ And I don't think that is a bad thing. It's good to be able to be flexible. Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug --- ## #50447 — Ferenc Kovacs — 2010-11-23T14:10:26+00:00 URL: https://externals.io/message/50415#50447 · In reply to: #50443 > > > > […] > so > > […] > > And I don't think that is a bad thing. It's good to be able to be > flexible. > > Derick > > Its good for you, but its bad for the people, who expect you to follow the rules, you know, the vendors, developers, etc. Tyrael --- ## #50448 — Matthew Weier O'Phinney — 2010-11-23T14:17:49+00:00 URL: https://externals.io/message/50415#50448 · In reply to: #50443 > > > […] > > And I don't think that is a bad thing. It's good to be able to be > flexible. A good artist is capable of great flexibility within the constraints of their medium. In the case of software releases, you can still have greate flexibility even with an existing release process. In many ways, having the process defined helps bring about creative solutions -- "if I want to get this in time for the release, what solution will work best?" I used to love the ad hoc nature of "we'll release when it's ready." However, having done quite a number of scheduled releases, I've found that: * Predictability motivates developers. "Release is in 3 months? Okay, let's get rolling on this!" * Knowing when the next release is coming also means that developers are more comfortable if they're unable to make the deadline. "I can't do it by this release, but I should have no trouble making the next." * Less stressful for release managers. If the code isn't ready by the deadline, it's not merged to the branch, plain and simple. The status quo works great for those whom it serves. For everyone else, it stinks. There's no transparency, which leads to disenfranchisement. -- Matthew Weier O'Phinney Project Lead | matthew@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc --- ## #50453 — Derick Rethans — 2010-11-23T14:48:26+00:00 URL: https://externals.io/message/50415#50453 · In reply to: #50448 > The status quo works great for those whom it serves. For everyone else, > it stinks. There's no transparency, which leads to disenfranchisement. That's why my first reply said: I don't mind a yearly release cycle, as we should get out more releases. I don't mind a monthly release cycle for .z releases. *that* is a good thing. regards, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug --- ## #50458 — Derick Rethans — 2010-11-23T14:58:29+00:00 URL: https://externals.io/message/50415#50458 · In reply to: #50447 > > > > […] > Its good for you, but its bad for the people, who expect you to follow the > rules, you know, the vendors, developers, etc. Well, vendors don't follow rules in the first place. They just add random patches anyway. Developers are pretty much aware what a bug fix, security bug fix and development tree means. With an annoucement (which should really be a regular thing, sortof) of a new minor release, isn't it clear? In case you say no, don't write an RFC that requires really strict following, but instead write guidelines that match current practise. Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug --- ## #50460 — Ferenc Kovacs — 2010-11-23T15:13:52+00:00 URL: https://externals.io/message/50415#50460 · In reply to: #50458 > > > > […] > the > > […] > > Well, vendors don't follow rules in the first place. you are sure that there aren't any vendor out there that don't following your rules, which you think it better if it isn't documented or followed? > They just add > random patches anyway. usually they more lazy, than the original developers, so I think they don't add random shit just for fun. > Developers are pretty much aware what a bug fix, > security bug fix and development tree means. as long as you and Zeev can't agree on what is the trunk (either be that a development/experience branch, or the next stable version), then I think they aren't aware. > With an annoucement (which > should really be a regular thing, sortof) of a new minor release, isn't > it clear? sorry, I lost you here. what is clear? that you want to release the current trunk? thats crystal clear. What it's not clear to me, that who decided when that you will be the current RM, and that the current trunk is ready for an alpha release. what is an alpha release? when did we started releasing and announcing alphas, who decided that? can we add new features after the alpha? or can we remove something if the feedback is bad about some change? so this is what I'm talking about, lack of > In case you say no, don't write an RFC that requires really > strict following, but instead write guidelines that match current > practise. > > from my POV, I don't mind, if you guys decide that the current process is the best, and create a wiki for that, but please decide on that, write it down, and at least try to stick with it, if it works. thats the point. Tyrael --- ## #50462 — Ilia Alshanetsky — 2010-11-23T18:24:14+00:00 URL: https://externals.io/message/50415#50462 · In reply to: #50420 I think support 5 or even 3 parallel versions will be highly impractical and extra-ordinarily challenging. I think we need a plan that limits us to 2 versions and perhaps a 3rd one for critical security fixes only. 2010/11/23 Johannes Schlüter : > Hi, > > > > […] > > Thanks for preparing this. I have one change proposal: > > With the proposed model it might, as you have illustrated, happen that > there are 5 versions being maintained. > > As I mentioned multiple times on this list, on irc and other places I > like a Ubuntu-like model with two kinds of release which I, for the > purpose of this discussion, call "early access" (EA) and "long term > supported" (LTS) version. > > At any given time only one EA may exist. When a new LTS version is being > released the previous LTS version enters security-only mode to give > users a transition period. Between every LTS version there are two EA > versions. > >       2011        2012       2013         2014        2015        2016        2017 >        |     |     |     |     |     |     |     |     |     |     |     |     | > LTS1    +++++++++++++++++++++++++++++++++++++-----------D     |     |     |     | > EA1     |     |     ++++++++++++D     |     |     |     |     |     |     |     | > EA2     |     |     |     |     ++++++++++++D     |     |     |     |     |     | > LTS2    |     |     |     |     |     |     ++++++++++++++++++++++++++++++++++++-----------D > EA3     |     |     |     |     |     |     |     |     ++++++++++++D > EA4     |     |     |     |     |     |     |     |     |     |     ++++++++++++D > > The benefit is that developers and users who require a specific feature > get it early while distributors/hosters/software vendors/... have a safe > bet. > > johannes --- ## #50464 — Ferenc Kovacs — 2010-11-23T19:34:05+00:00 URL: https://externals.io/message/50415#50464 · In reply to: #50462 2010/11/23 Ilia Alshanetsky > I think support 5 or even 3 parallel versions will be highly > impractical and extra-ordinarily challenging. I think we need a plan > that limits us to 2 versions and perhaps a 3rd one for critical > security fixes only. > > 2010/11/23 Johannes Schlüter : > > […] > [1] > > […] > 2017 > > […] > | | > > […] > | | > > […] > | | > > […] > | | > > […] > ++++++++++++++++++++++++++++++++++++-----------D > > […] > ++++++++++++D > > […] > > -- > > > > You can't expect the users to switch to the new major version as soon as it comes out. They have to either migrate their codebase, and sadly they will wait(at least me and my collegues/friends do this) one or two micro/build version bump, usually the new major/major.minor version is stable enough. So if we want to support "equally" 2 major version concurrently, I can't see how can we make it through supporting 4 branches (oldmajor.last, oldmajor.current, newmajor.last, newmajor.current) or we can make "unequal" or "favored" branches: - either an early adopter vs lts sytem like ubuntu does, but they have 4 supported version at a time also https://wiki.ubuntu.com/LTS but I don't know how to mix LTS and php, because they release "shared nothing" versions, while the php versions does share a common codebase through their major version, so we can't plan beforehand that what version will be the nextlts before getting there like the ubuntu guys can. :/ - or stopping the development on the oldmajor version (I mean no new minor version for the oldmajor, only micro/build bugfix releases) with that modification, the multiple major version would be like this: http://wiki.php.net/rfc/releaseprocessalternatives what do you think? Tyrael --- ## #50479 — Pierre Joye — 2010-11-25T01:07:22+00:00 URL: https://externals.io/message/50415#50479 · In reply to: #50462 hi, 2010/11/23 Ilia Alshanetsky : > I think support 5 or even 3 parallel versions will be highly > impractical and extra-ordinarily challenging. I think we need a plan > that limits us to 2 versions and perhaps a 3rd one for critical > security fixes only. Yes, that's what the two examples tried to show. Also reducing the bugs fixing period (move earlier to security mode only) could help a lot. Having one release in bugs fixes mode and two in security only is not too much work. The one thing we have to improve to achieve this goal (be 2 or 3 active versions) is to share tests infrastructure. At our labs we are working on improving our tests platforms with more BC tests, performance/stress tests and apps testing using the usual apps (wp, joomla, drupal, etc.) with setup and usage. We would like to add frameworks too soonish, but for that we would prefer to work with the framework directly. Doing so will let us tests a RC withing a couple of days with a high level of confidence. I also think that with a bug fixes and security only mode will reduce a release period to a month (2 RCs) for 99% of the releases. Feel free to ping me if you are one of the QA lead/lead of a framework or app and have a tests suite ready to be used. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #50480 — Pierre Joye — 2010-11-25T01:07:42+00:00 URL: https://externals.io/message/50415#50480 · In reply to: #50448 hi, amen. On Tue, Nov 23, 2010 at 3:17 PM, Matthew Weier O'Phinney wrote: > > > […] > > A good artist is capable of great flexibility within the constraints of > their medium. In the case of software releases, you can still have > greate flexibility even with an existing release process. In many ways, > having the process defined helps bring about creative solutions -- "if I > want to get this in time for the release, what solution will work best?" > > I used to love the ad hoc nature of "we'll release when it's ready." > However, having done quite a number of scheduled releases, I've found > that: > >  * Predictability motivates developers. "Release is in 3 months? Okay, >   let's get rolling on this!" > >  * Knowing when the next release is coming also means that developers >   are more comfortable if they're unable to make the deadline. "I can't >   do it by this release, but I should have no trouble making the next." > >  * Less stressful for release managers. If the code isn't ready by the >   deadline, it's not merged to the branch, plain and simple. > > The status quo works great for those whom it serves. For everyone else, > it stinks. There's no transparency, which leads to disenfranchisement. > > -- > Matthew Weier O'Phinney > Project Lead            | matthew@zend.com > Zend Framework          | http://framework.zend.com/ > PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc > > -- > > > > -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #50493 — Stas Malyshev — 2010-11-25T05:38:41+00:00 URL: https://externals.io/message/50415#50493 · In reply to: #50430 Hi! > > […] > > Really? I think you're blowing this all way out of proportion. > > I don't mind a yearly release cycle, as we should get out more releases. > I don't mind a monthly release cycle for .z releases. I think the idea is not focusing on "yearly" or "monthly" but having some predictable schedule. Nobody says it should be set in stone, let's be realistic here - if we need to slip a release here and there, we'd do it. But having known targets is the goal, not having releases "whenever somebody on the list wakes up and decides to have a release". I think the project needs to grow up a bit and have at least some semblance of release schedule. The mere existence of it written somewhere public would motivate people to adhere to it. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #50495 — Andi Gutmans — 2010-11-25T06:42:17+00:00 URL: https://externals.io/message/50415#50495 · In reply to: #50493 > -----Original Message----- > From: Stas Malyshev [mailto:smalyshev@sugarcrm.com] > Sent: Wednesday, November 24, 2010 9:39 PM > To: Derick Rethans > Cc: Felipe Pena; internals > Subject: Re: [PHP-DEV] [RFC] Release Process > > Hi! > > > […] > > I think the idea is not focusing on "yearly" or "monthly" but having some > predictable schedule. Nobody says it should be set in stone, let's be realistic > here - if we need to slip a release here and there, we'd do it. But having known > targets is the goal, not having releases "whenever somebody on the list wakes > up and decides to have a release". I think the project needs to grow up a bit and > have at least some semblance of release schedule. The mere existence of it > written somewhere public would motivate people to adhere to it. I agree with that. More structure and predictability will be very valuable to the project. We created a lot of structure in Zend Framework and it has really paid off. Btw, we don't have to look far. Just the change in having people document their suggestions via RFCs already had a substantial impact on this project both in terms of peer review and having a long lasting trail of what made it into a given release. More structure will typically yield in higher quality, more visibility and therefore more motivation for people to contribute, and I believe also in more deliverables rather than less as people will work towards clear goals + be accepting if they miss them and they need to wait for the next release train. Andi --- ## #50505 — Pierre Joye — 2010-11-25T08:48:20+00:00 URL: https://externals.io/message/50415#50505 · In reply to: #50495 hi Andi, > I agree with that. More structure and predictability will be very valuable to the project. We created a lot of structure in Zend Framework and it has really paid off. > Btw, we don't have to look far. Just the change in having people document their suggestions via RFCs already had a substantial impact on this project both in terms of peer review and having a long lasting trail of what made it into a given release. > More structure will typically yield in higher quality, more visibility and therefore more motivation for people to contribute, and I believe also in more deliverables rather than less as people will work towards clear goals + be accepting if they miss them and they need to wait for the next release train. As we will stay flexible, a fixed time time to begin with is better. The other key part was about features selection, unlike what has been done (or suggested in this thread), we should take what is done but what we what is ready and desired. Desired as in tested (viable, BC, QAs, etc.) and desired (RFC, votes, etc.). A fixed time line also helps developers to catch the next band wagon if they miss one, instead of pushing in half backed additions. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #50515 — David Soria Parra — 2010-11-25T10:47:29+00:00 URL: https://externals.io/message/50415#50515 · In reply to: #50415 > --001636eef06580573f0495ae312f > Content-Type: text/plain; charset=UTF-8 > > Hi, > > With the recent chaos in the way we begin and ended releases, we would > like to propose a clean way to deal with releases and related decisions: [1] > > PHP releases have always been done spontaneously, in a somehow chaotic > way. Individual(s) decided when a release will happen and what could > or could fit in. Release managers role are unclear and the way to > nominate them is not clearly defined either. > > The goals of this RFC aim to solve these issues while giving to us, > our users and 3rd parties (distributions, contributors, etc.) more > visibility and the ability to actually have a roadmap, or plan > developments. This RFC aims to define: > > * a clear release cycle, periodic > * a transparent decision process for the feature additions, via > the RFCs and a transparent but anonymous vote > * which changes can be done during a release lifetime (BC breaks, > bugs fixes, security fixes, etc.) > * a transparent way to choose release managers for a given release > * a better usage of bugs.php.net to track each change, addition, > bug fixes (security incl.) or other various tasks related to a release > * reduce time between bugs fix releases > * reduce the time to get new features in a release > * suppress BC breaks in bugs fix releases > * feature(s) preview release thanks for preparing this, as matthew and andi pointed out, more structure is a good idea. I still think even with all the things in the RFC in place, we are still very flexible. Having planned releases and clear processes how to reduce BCs and add transparency was always a good thing in the projects I worked on. So I'm definatly in favor of this. --- ## #50532 — Derick Rethans — 2010-11-25T15:09:37+00:00 URL: https://externals.io/message/50415#50532 · In reply to: #50415 > [1] http://wiki.php.net/rfc/releaseprocess Now I've thought a bit more about it, I'm trying to reply to this with some constructive comments. I'm reordering it a bit in the response where it makes sense to do. In a general way, some of the things in here are done, and IMO it make sense to refine them during the 5.4 process if we find that things don't work as this theoretical RFC implies. > ===== Releases Cycle ===== > > No feature addition after final x.y.0 release (or x.0.0). Self > contained features or new SAPIs could be carefully considered on a > case by case basis. > > Backward compatibility must be respected with the same major releases, > for example from 5.2 to 5.6. Binary compatibility can be broken > between two features releases, f.e. between 5.3 and 5.4: > > * x.y.z to x.y.z+1 > * Bugs fixes only (with a room for exceptions on a case by case > basis and only for small self contained features additions). > * Extensions support can't be removed (like move them to pecl) > * Backward compatibility must be kept (internals and userland) > * ABI/API compatibility must be kept (internals) > * x.y.z to x.y+1.z > * Bugs fixes > * New features > * Extensions support can be ended (moved to pecl) > * Backward compatibility must be kept > * API compatibility must be kept (internals and userland) > * ABI can be broken (internals) > * x.y.z to x+1.0.0 > * Bugs fixes > * New features > * Extensions support can be ended (moved to pecl) > * Backward compatibility can be broken > * API compatibility can be broken (internals and userland). > * ABI can be broken (internals) > > It is critical to understand the consequences of breaking BC, APIs or > ABIs. It should not be done for the sake of doing it. RFCs explaining > the reasoning behind a breakage and the consequences along with test > cases and patch(es) should help. The whole section above is really nothing new, but good to write down. > * Yearly release cycle > * 3 years release life cycle > * 2 years bugs fixes only > * 1 year security fixes only > > ==== Example time line with only one major version at a time ==== > > **** 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 > > > > ==== 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. > > **** 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 > 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. > ==== Timeline example for a release ==== > > > * January > * 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 > * March, 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 > * June, 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". I am also thinking that it might be better to not start in January, but in September/October so that a new release doesn't come out just before the summer holidays. > ===== 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. > ===== Release managers selection ===== > > The release managers team should be selected in a more transparent > way. The ideal way is again to go through a proposal and a vote. The > same system than the RFCs can obviously be used for the release > managers selection. > > The volunteers (a team of two persons) can add propose themselves via > the mailing list and they will be added to a RFC page. A week between > the last call and the vote should be sufficient (given that anyone can > volunteer himself for the next release at any time). The vote takes > place for a week. > > Examples: > * John/Fred (yes, no) > * Ted/Georges (yes, no) > * Leon/Nikita (yes, no) > > The team with the most votes will be then the RMs for the given > release. One person cannot be a RM for more than one release at the > same time. > > Again, one of the questions 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 Sounds like something we might want to look at for feature releases (from 5.5). > ===== 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 --- ## #51144 — Enrico Weigelt — 2010-12-31T03:59:37+00:00 URL: https://externals.io/message/50415#51144 · In reply to: #50464 * Ferenc Kovacs wrote: > You can't expect the users to switch to the new major version as soon as it > comes out. They have to either migrate their codebase, and sadly they will > wait(at least me and my collegues/friends do this) one or two micro/build > version bump, usually the new major/major.minor version is stable enough. ACK. One of my customers, a major ISP with millions of customers, often sticks in older versions as newer ones tend to break many things. Just had such a problem myself a few weeks ago: a minor update (IIRC was from 5.3.2 to 5.3.3) broke virtually all of my web applications (had to do lots of config adaptions to get it running again ;-o). I got the strange feeling that php-devs don't care very much of long term stability ;-p It's more a problem of careful API/feature design than release cycling. Once some feature or interface is in stable branch, it should stay there w/o any disturbance at least until next *major* release. > So if we want to support "equally" 2 major version concurrently, I can't see > how can we make it through supporting 4 branches (oldmajor.last, > oldmajor.current, newmajor.last, newmajor.current) > > or we can make "unequal" or "favored" branches: > - either an early adopter vs lts sytem like ubuntu does, but they have 4 > supported version at a time also > https://wiki.ubuntu.com/LTS > but I don't know how to mix LTS and php, because they release "shared > nothing" versions, while the php versions does share a common codebase > through their major version, so we can't plan beforehand that what version > will be the nextlts before getting there like the ubuntu guys can. :/ Why not using a branch hierachy ? * new major branch is forked from latest release tag when compatibility breaks will occour (properly planned and only done if *necessary*, eg. like 4.x -> 5.x). * for each minor release, a separate branch is forked on the latest stable tag. * bugs in a minor releases are fixed in these branches and micro releases tagged out from there. * canonical versioning scheme: A.B.C (the 4th digit is reserved for distros / downstreams) * all issues (bugfixes, features, etc) are done in their own per-issue branches, which get rebased to their parent branch before merging back. Scenario A: bugfixing. -> found a bug in 5.3.4, reporting as bug# 12345 -> forking a branch bugfix_5.3.4_12345 from release-5.3.4 -> fixing the bug, testing until everything's fine -> rebasing to latest php-5.3 branch and maybe retest. -> submit my bugfix branch for review, until aggreed to be fine -> rebase to latest php-5.3 again and merge into it -> tag a new release from that branch -> rebase to to latest master branch (that will become 5.4), test again and merge if still applicable there Scenario B: new feature -> inventing some super-new feature, which will take a while to be stableized -> fork from latest stable release or master branch (whatever seems applicable, on when the feature might get into mainline) -> do development here, possible rework multiple times -> frequently rebase to new releases or master branch -> plan into which release the feature will get in -> when properly reviewed/tested/accepted, rebased to latest master and merge into it cu -- ---------------------------------------------------------------------- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weigelt@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 ---------------------------------------------------------------------- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme --- ## #51146 — Stas Malyshev — 2010-12-31T05:25:48+00:00 URL: https://externals.io/message/50415#51146 · In reply to: #51144 Hi! > Just had such a problem myself a few weeks ago: a minor update > (IIRC was from 5.3.2 to 5.3.3) broke virtually all of my web applications Out of curiosity - what exactly broke it? What change was it? > I got the strange feeling that php-devs don't care very much of long > term stability ;-p If enough people would actually test pre-releases, the probability of this happening would be lower. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #51147 — Ferenc Kovacs — 2010-12-31T08:29:58+00:00 URL: https://externals.io/message/50415#51147 · In reply to: #51146 On Fri, Dec 31, 2010 at 6:25 AM, Stas Malyshev wrote: > Hi! > > > Just had such a problem myself a few weeks ago: a minor update > > […] > > Out of curiosity - what exactly broke it? What change was it? > > > I got the strange feeling that php-devs don't care very much of long > > […] > > If enough people would actually test pre-releases, the probability of this > happening would be lower. > Btw: maybe we could announce the RCs to a wider audience. I mean announce it on the site, tweet/blog about it, ask the community for testing and feedback. currently only thoose who closely follow the development (subscribed to the mailing lists) are aware the general direction and status of the development. what do you think? Tyrael --- ## #51148 — Patrick ALLAERT — 2010-12-31T08:36:11+00:00 URL: https://externals.io/message/50415#51148 · In reply to: #51147 2010/12/31 Ferenc Kovacs : > On Fri, Dec 31, 2010 at 6:25 AM, Stas Malyshev wrote: [snip] > Btw: maybe we could announce the RCs to a wider audience. > I mean announce it on the site, tweet/blog about it, ask the community for > testing and feedback. > currently only thoose who closely follow the development (subscribed to the > mailing lists) are aware the general direction and status of the > development. > > what do you think? Definitely a *HUGE* +1 ! --- ## #51150 — Enrico Weigelt — 2010-12-31T11:49:27+00:00 URL: https://externals.io/message/50415#51150 · In reply to: #51146 * Stas Malyshev wrote: > Hi! > > > […] > > Out of curiosity - what exactly broke it? What change was it? IIRC many deprecation warnings, which totally broke the output. I guess with the next release I can expect certain warnings to become true and certain functionality disappearing ;-o > > […] > > If enough people would actually test pre-releases, the probability of > this happening would be lower. I, personally, have no time to test prereleases of dozens of packages (php is just one of dozens I'm using, not in the list of those I'm actively developing on). I use the packages of my distro (Gentoo), which has an own release process where new packages first masked as unstable and only get stabelized after some testing period - even this didn't catch this. Even large distros cannot test everything. IMHO there's a fundamental flaw in the development process: existing semantics in a stable line should _never_ change. Things like certain superglobals or calltime-reference passing should neither disappear or suddenly produce warnings within the stable line. The whole idea of depcreation warnings which explicitly have to be switched off is insane from the operator's perspective - it means a semantic change which requires each single php application to be tested in realworld scenarios before rolling out a new php version to production servers, leading to imensive costs simply driving people away from php completely. I really can understand the idea of these warnings, as well as removing things like superglobals, from development perspective. But they better belong into an additional instrumentation system which does not affect the behaviour of the running applications (eg. send these warnings to syslog instead of stdout, unless _explicitly_ asked to do otherwise). cu -- ---------------------------------------------------------------------- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weigelt@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 ---------------------------------------------------------------------- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme --- ## #51162 — Rasmus Lerdorf — 2010-12-31T17:10:54+00:00 URL: https://externals.io/message/50415#51162 · In reply to: #51150 > * Stas Malyshev wrote: > > […] > > IIRC many deprecation warnings, which totally broke the output. > I guess with the next release I can expect certain warnings to > become true and certain functionality disappearing ;-o Your application broke because of a deprecation warning? Are you sending PHP errors to the user in your production code? At most this should have caused some extra lines in your error log which end users should never ever see. -Rasmus --- Next page: https://externals.io/message/50415.md?page=2