Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » Learning from Python: PEPping the PHP Development Process »

Learning from Python: PEPping the PHP Development Process

php.internals

Sebastian Bergmann

22 years ago
At last weekend's EuroFoo [1] I attended Marc-Andre Lemburg's talk [2] on the Python development process. I really wish we had a process similar to Python's PEPs [3] [4] for PHP. Having guidelines for issues like adding a new module [5] or deprecating a module [6] not only makes the development consistent but also transparent to our users. Wishfully thinking, Sebastian (who knows that it might not be his place to call for a change like this given that he is not a core developer)
-- [1] http://wiki.oreillynet.com/eurofoo/index.cgi [2] http://www.egenix.com/files/python/EuroPython2004-How-Python-is-developed.pdf [3] http://www.python.org/peps/ [4] http://www.python.org/peps/pep-0001.html [5] http://www.python.org/peps/pep-0002.html [6] http://www.python.org/peps/pep-0004.html -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Das Buch zu PHP 5: http://professionelle-softwareentwicklung-mit-php5.de/

Rasmus Lerdorf

22 years ago
On Thu, 26 Aug 2004, Sebastian Bergmann wrote:
> At last weekend's EuroFoo [1] I attended Marc-Andre Lemburg's talk [2] > on the Python development process. > > I really wish we had a process similar to Python's PEPs [3] [4] for PHP. > > Having guidelines for issues like adding a new module [5] or deprecating > a module [6] not only makes the development consistent but also > transparent to our users.
It smells a little too processy to me, but I wouldn't mind a system that borrowed some of the ideas. Like a single collection point for feature proposals and a common format for them. We could simply steal PEAR's PEPR infrastructure for this (http://pear.php.net/pepr/pepr-overview.php). -Rasmus

Sebastian Bergmann

22 years ago
Rasmus Lerdorf wrote:
> It smells a little too processy to me, but I wouldn't mind a system > that borrowed some of the ideas.
That is exactly why chose "Learning ..." and not "Adopting ..." :-) We should have a look at it and see for ourselves what could work for us.
> Like a single collection point for feature proposals and a common > format for them.
This would be a huge step forward, IMHO, as we would then have a central site to point users to in order to look up design decisions, etc.
> We could simply steal PEAR's PEPR infrastructure for this
I was thinking along the same lines.
> -Rasmus
Greetings, Sebastian
-- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Das Buch zu PHP 5: http://professionelle-softwareentwicklung-mit-php5.de/

Greg Beaver

22 years ago
Rasmus Lerdorf wrote:
> On Thu, 26 Aug 2004, Sebastian Bergmann wrote: > >> At last weekend's EuroFoo [1] I attended Marc-Andre Lemburg's talk [2] >> on the Python development process. >> >> I really wish we had a process similar to Python's PEPs [3] [4] for PHP. >> >> Having guidelines for issues like adding a new module [5] or deprecating >> a module [6] not only makes the development consistent but also >> transparent to our users. > > > It smells a little too processy to me, but I wouldn't mind a system that > borrowed some of the ideas. Like a single collection point for feature > proposals and a common format for them. We could simply steal PEAR's PEPR > infrastructure for this (http://pear.php.net/pepr/pepr-overview.php).
PEPr has been pretty useful, but there are some pitfalls with the current design of PEPr. It seems that in the proposal stage, most developers don't even notice a package. At the voting stage, the proposal can't be modified (for obvious reasons), and so many flame wars have erupted from those who have not noticed it versus those who have devoted lots of energy to it. Also, since developers tend to be gone occasionally, the voting period of 2 weeks can sometimes be too short to get a real sense of consensus. I'd say the best aspect of PEPr is the centralized location for all ideas. Using voting to make decisions is in my opinion somewhat of a failure though. Voting could more successfully be used to determine popularity/necessity of a feature or proposal (i.e. allow people with cvs accounts to not only vote, but to change their vote as they learn more about a feature). Then the developers can react better to the users' changing needs. Also, PHP has very active and clear leaders in Zeev and Andi, and so decision-making won't need to be as democratic as it might otherwise have to be. I don't mean to discourage the idea, but if you do decide to go with a PEPr-like system, it would be good to learn from PEAR's first go at it. Greg

Sebastian Bergmann

22 years ago
Greg Beaver wrote:
> PEPr has been pretty useful, but there are some pitfalls with the > current design of PEPr.
Most notably that everyone is allowed to vote ie. thinks his vote should matter? When it comes to voting I think it should not be democratic but meritocratic.
-- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Das Buch zu PHP 5: http://professionelle-softwareentwicklung-mit-php5.de/

Hartmut Holzgraefe

22 years ago
Sebastian Bergmann wrote:
> When it comes to voting I think it should not be democratic but > meritocratic.
whereas we now are mostly do-o-cratic (a nice term that came up at EuroFoo although i don't remember where i picked it up ...)
-- Hartmut Holzgraefe <hartmut@php.net>

Sebastian Bergmann

22 years ago
Hartmut Holzgraefe wrote:
> whereas we now are mostly do-o-cratic (a nice term that came up > at EuroFoo although i don't remember where i picked it up ...)
Which is just colloquial for meritocratic, AFAICS :-)
-- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Das Buch zu PHP 5: http://professionelle-softwareentwicklung-mit-php5.de/

Hartmut Holzgraefe

22 years ago
Sebastian Bergmann wrote:
> Hartmut Holzgraefe wrote: > >> whereas we now are mostly do-o-cratic (a nice term that came up >> at EuroFoo although i don't remember where i picked it up ...) > > > Which is just colloquial for meritocratic, AFAICS :-) >
No, as your vote doesn't get more important in general as you contribute. Instead you vote for a certain way of doing something and the most effective way of voting against this is to implement a different approach. (as far as i understood) PS: i remember now that the Skolelinux project came up with this term
-- Hartmut Holzgraefe <hartmut@php.net>

Sebastian Bergmann

22 years ago
Hartmut Holzgraefe wrote:
> No, as your vote doesn't get more important in general as you > contribute. Instead you vote for a certain way of doing something > and the most effective way of voting against this is to implement > a different approach. (as far as i understood)
Hm, I always thought that the concept you describe was called meritocracy because the value of your vote is based on the merit you brought to the project. Sorry for confusing this, Sebastain
-- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Das Buch zu PHP 5: http://professionelle-softwareentwicklung-mit-php5.de/

Andi Gutmans

22 years ago
It might be nice to have this documentation in place for people to reference and for discussions (and most importantly to look back at for understanding design decisions). It also would make it easier for people to propose new features or changes in PHP. This doesn't necessarily have to do with voting. In general, the PHP project up to now has worked pretty well in this sense. Like in most open-source projects the maintainer of a certain piece of PHP usually has more say than others (and thank god we have many maintainers and not an individual person for the whole thing). That doesn't mean that overwhelming popular demand hasn't had it affects either. I think it's a balance which can only be reached by cooperation. Andi At 02:06 PM 8/26/2004 -0400, Greg Beaver wrote:

Rasmus Lerdorf

22 years ago
Just to clarify, I didn't propose taking the PEAR PEPr system verbatim. To be honest, I have never really used it, beyond skimming through things because it is handy that everything is in one place. I don't find our feature/change request category in the bugs database to be all that effective. Things tend to get lost in the noise there. I am not sure it would be effective, but I think it might be worth a try to have a single place for people to propose features and changes and to have an organized record of decisions surrounding these proposals. At the same time I absolutely hate using a web system for discussing things, so such a system should have an email gateway. As in: 1. Submit proposal to web app 2. web app sends it to internals@ or some other relevant list 3. Replies to that email automatically get picked up by the web app 4. Alternatively, you can add comments via the web app which would also get bounced to the relevant mailing list -Rasmus On Thu, 26 Aug 2004, Andi Gutmans wrote:

Sterling Hughes

22 years ago
Rasmus Lerdorf wrote:
>Just to clarify, I didn't propose taking the PEAR PEPr system verbatim. >To be honest, I have never really used it, beyond skimming through things >because it is handy that everything is in one place. I don't find our >feature/change request category in the bugs database to be all that >effective. Things tend to get lost in the noise there. > >I am not sure it would be effective, but I think it might be worth a try >to have a single place for people to propose features and changes and to >have an organized record of decisions surrounding these proposals. At the >same time I absolutely hate using a web system for discussing things, so >such a system should have an email gateway. > >As in: > > 1. Submit proposal to web app > 2. web app sends it to internals@ or some other relevant list > 3. Replies to that email automatically get picked up by the web app > 4. Alternatively, you can add comments via the web app which would > also get bounced to the relevant mailing list > > >
One thing we could do is have a "TAG" message in our existing lists, when a discussion like this one becomes noteworthy, someone could respond with a subject "[TAG: Feature Request]" and that would propagate the conversation to the necessary portion of the web app? -Sterling

Sebastian Bergmann

22 years ago
Rasmus Lerdorf wrote:
> 1. Submit proposal to web app > 2. web app sends it to internals@ or some other relevant list > 3. Replies to that email automatically get picked up by the web app > 4. Alternatively, you can add comments via the web app which would > also get bounced to the relevant mailing list
Then again, why use a webapp at all? AFAICS, Python uses a special directory in CVS [1] to which the PEPs are added. I think there is a certain beauty to this "low-tech" approach as you get access control and history out-of-the-box from CVS. And through the CVS commit mails one can easily follow the process via mail.
-- [1] http://cvs.sf.net/viewcvs.py/python/python/nondist/peps/ -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Das Buch zu PHP 5: http://professionelle-softwareentwicklung-mit-php5.de/

Rasmus Lerdorf

22 years ago
On Fri, 27 Aug 2004, Sebastian Bergmann wrote:
> Rasmus Lerdorf wrote: > > 1. Submit proposal to web app > > 2. web app sends it to internals@ or some other relevant list > > 3. Replies to that email automatically get picked up by the web app > > 4. Alternatively, you can add comments via the web app which would > > also get bounced to the relevant mailing list > > Then again, why use a webapp at all? AFAICS, Python uses a special > directory in CVS [1] to which the PEPs are added.
Well, the same could be said of the bug report system. I think having a more accessible interface is the entire point here. A single place for tracking features and proposals and making it easier to later go back and review the discussion. Right now it becomes a treasure hunt through the mailing list archives that we don't have any control over to begin with and it really is quite a hassle to go spelunking for the reasons things were done the way they were done. It would guide people to how to actually submit an idea in a structured way, and more importantly, it would hopefully stop people from suggesting the same stupid feature that someone else had already suggested and was shot down. I suppose it ends up being a filtered and structured view of the development mailing list where general chit-chat is filtered out and each tracked thread is about a specific feature or enhancement. This sort of email tie-in has been on my wishlist for the bug system for years as well. Bugzilla does this quite well, but we never got around to adding it to ours. I'll have a look at this CLEW system and see if I can come up with a prototype. -Rasmus

Daniel Convissor

22 years ago
[Oops. Send this email directly to Rasmus rather than the list...] On Thu, Aug 26, 2004 at 12:58:21PM -0700, Rasmus Lerdorf wrote:
> 2. web app sends it to internals@ or some other relevant list > 3. Replies to that email automatically get picked up by the web app > 4. Alternatively, you can add comments via the web app which would > also get bounced to the relevant mailing list
nyphp.org is working on something called CLEW, which will be able to do exactly that. See the following links for more info: http://clew.nyphp.org/clew/clew http://nyphp.org/content/presentations/nyphp/index.php?slide=13 --Dan
-- T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y data intensive web and database programming http://www.AnalysisAndSolutions.com/ 4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409

Sterling Hughes

22 years ago
Rasmus Lerdorf wrote:
>On Thu, 26 Aug 2004, Sebastian Bergmann wrote: > > >> At last weekend's EuroFoo [1] I attended Marc-Andre Lemburg's talk [2] >> on the Python development process. >> >> I really wish we had a process similar to Python's PEPs [3] [4] for PHP. >> >> Having guidelines for issues like adding a new module [5] or deprecating >> a module [6] not only makes the development consistent but also >> transparent to our users. >> >> > >It smells a little too processy to me, but I wouldn't mind a system that >borrowed some of the ideas. Like a single collection point for feature >proposals and a common format for them. We could simply steal PEAR's PEPR >infrastructure for this (http://pear.php.net/pepr/pepr-overview.php). > >
It smells a bit too processy anyway you swing it, and maybe I'm missing something, but I don't see any need: I'd like to see a problem before we attempt to fix it. -Sterling

Derick Rethans

22 years ago
On Thu, 26 Aug 2004, Sebastian Bergmann wrote:
> At last weekend's EuroFoo [1] I attended Marc-Andre Lemburg's talk [2] > on the Python development process. > > I really wish we had a process similar to Python's PEPs [3] [4] for > PHP. > > Having guidelines for issues like adding a new module [5] or > deprecating a module [6] not only makes the development consistent but > also transparent to our users.
What is wrong with how we currently do it? regards, Derick
-- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org

Christian Stocker

22 years ago
On 27.8.2004 8:59 Uhr, Derick Rethans wrote:
> On Thu, 26 Aug 2004, Sebastian Bergmann wrote: > > >>At last weekend's EuroFoo [1] I attended Marc-Andre Lemburg's talk [2] >>on the Python development process. >> >>I really wish we had a process similar to Python's PEPs [3] [4] for >>PHP. >> >>Having guidelines for issues like adding a new module [5] or >>deprecating a module [6] not only makes the development consistent but >>also transparent to our users. > > > What is wrong with how we currently do it?
Agreed. I don't like PEpr, I don't like the PEAR voting process and the PHP developement process works quite well how it is (I'm aware of the fact, the PHP wouldn't just take PEAR's model as-it-is, but nevertheless...). Actually, other people i talk to are always impressed, how this "chaotic", based-on-common-agreement developement process actually works at all ;) This doesn't stop us from having some PEP-like documents, which clearly define some common rules, but I fear we end up in heavy discussions on wording and details. See the PEAR mailinglists for an example ;) chregu
-- christian stocker | Bitflux GmbH | schoeneggstrasse 5 | ch-8004 zurich phone +41 1 240 56 70 | mobile +41 76 561 88 60 | fax +41 1 240 56 71 http://www.bitflux.ch | chregu@bitflux.ch | gnupg-keyid 0x5CE1DECB

Hartmut Holzgraefe

22 years ago
Christian Stocker wrote:
> Actually, other people i talk to are always impressed, how this > "chaotic", based-on-common-agreement developement process actually works > at all ;)
Well, one reason might be no matter how fuzzy the process there are some very clear metrics for the result, like e.g. "compiles", "passes tests" or, a little more fuzzy but still rather fact-based, "works". And you can apply all these to different scales of changes. Combine this with the fact that the effort needed to implement changes does not include any noticable cost of creating a copy first and you'll find that creating software is very different to other forms of science, engineering and art.
> This doesn't stop us from having some PEP-like documents, which clearly > define some common rules, but I fear we end up in heavy discussions on > wording and details. See the PEAR mailinglists for an example ;)
oh yes, the only list that i'm subscribed to but have activated the "mark message as read" option in the filter ;)
-- Hartmut Holzgraefe <hartmut@php.net>

Derick Rethans

22 years ago
On Fri, 27 Aug 2004, Hartmut Holzgraefe wrote:
> Christian Stocker wrote: > > Actually, other people i talk to are always impressed, how this > > "chaotic", based-on-common-agreement developement process actually works > > at all ;) > > Well, one reason might be no matter how fuzzy the process > there are some very clear metrics for the result, like > e.g. "compiles", "passes tests" or, a little more fuzzy > but still rather fact-based, "works". And you can apply > all these to different scales of changes. Combine this > with the fact that the effort needed to implement changes > does not include any noticable cost of creating a copy > first and you'll find that creating software is very > different to other forms of science, engineering and > art.
We have some of this in our EXTENSIONS file in CVS. regards, Derick
-- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org

Christian Stocker

22 years ago
On 27.8.2004 9:58 Uhr, Hartmut Holzgraefe wrote:
> Christian Stocker wrote: > >> Actually, other people i talk to are always impressed, how this >> "chaotic", based-on-common-agreement developement process actually >> works at all ;) > > > Well, one reason might be no matter how fuzzy the process > there are some very clear metrics for the result, like > e.g. "compiles", "passes tests" or, a little more fuzzy > but still rather fact-based, "works". And you can apply > all these to different scales of changes. Combine this > with the fact that the effort needed to implement changes > does not include any noticable cost of creating a copy > first and you'll find that creating software is very > different to other forms of science, engineering and > art.
I wanted to compare it to other software projects (notably I spoked to some Mozilla guys about that topic and also some "commercial/proprietary" software developers), not to science et al. I'm an engineer by education, so I wouldn't dare to try to compare PHP developement process to eg. building a sewage plant (yeah, I learned how to do that ;) ) chregu
-- christian stocker | Bitflux GmbH | schoeneggstrasse 5 | ch-8004 zurich phone +41 1 240 56 70 | mobile +41 76 561 88 60 | fax +41 1 240 56 71 http://www.bitflux.ch | chregu@bitflux.ch | gnupg-keyid 0x5CE1DECB

Sebastian Bergmann

22 years ago
Derick Rethans wrote:
> What is wrong with how we currently do it?
We have currently nothing like it. Or if we do, I haven't notices it in the last couple of years. And if I haven't, chances are that our users haven't either :-)
-- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Das Buch zu PHP 5: http://professionelle-softwareentwicklung-mit-php5.de/

Jacques Marneweck

22 years ago
On Fri, 27 Aug 2004 09:11:58 +0200, Sebastian Bergmann <sb@sebastian-bergmann.de> wrote:
> Derick Rethans wrote: > > What is wrong with how we currently do it? > > We have currently nothing like it. Or if we do, I haven't notices it in > the last couple of years. And if I haven't, chances are that our users > haven't either :-) >
We could make our own version of a proposal system for this sort of thing. Also our 'bugs' system could use a slight overhaul to support adding file attachments, and various other features. We could make feature requests sent via bugs end up with a tag on the front by the time it hits the mailing list. Also we don't keep easy records on how to find the design decisions, as on always has to end up digging around the mailing list archives. I have a project on my TODO list which is to allow news.php.net to allow searching of mailing list posts for a start, but I have not had sufficient time to get this off the ground. Also I'm planning on getting threading to work properly, so that one can see a list of threads for a post, and can go up / down the thread similar lists.mysql.com which would make it easier to follow threads and find things on the mailing lists. Regards --jm
> -- > Sebastian Bergmann > http://sebastian-bergmann.de/ http://phpOpenTracker.de/ > > Das Buch zu PHP 5: http://professionelle-softwareentwicklung-mit-php5.de/ > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
-- Jacques Marneweck http://www.powertrip.co.za/blog/

Zeev Suraski

22 years ago
At 10:10 27/08/2004, Christian Stocker wrote:
>On 27.8.2004 8:59 Uhr, Derick Rethans wrote: >>On Thu, 26 Aug 2004, Sebastian Bergmann wrote: >> >>>At last weekend's EuroFoo [1] I attended Marc-Andre Lemburg's talk [2] >>>on the Python development process. >>> >>>I really wish we had a process similar to Python's PEPs [3] [4] for >>>PHP. >>> >>>Having guidelines for issues like adding a new module [5] or >>>deprecating a module [6] not only makes the development consistent but >>>also transparent to our users. >> >>What is wrong with how we currently do it? > >Agreed. I don't like PEpr, I don't like the PEAR voting process and the >PHP developement process works quite well how it is (I'm aware of the >fact, the PHP wouldn't just take PEAR's model as-it-is, but nevertheless...).
Me too. I would like to get some feedback about my suggestion to move away from the simple 'experimental' status and dividing it into two - quality rating, and 'API subject to change' tagging. Does this make sense to anybody else? Zeev

Derick Rethans

22 years ago
On Fri, 27 Aug 2004, Zeev Suraski wrote:
> I would like to get some feedback about my suggestion to move away from the > simple 'experimental' status and dividing it into two - quality rating, and > 'API subject to change' tagging. Does this make sense to anybody else?
yes, sounds much better than added bureaucrazy. Derick
-- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org

Ilia A.

22 years ago
On August 27, 2004 03:26 am, Zeev Suraski wrote:
> Me too. > I would like to get some feedback about my suggestion to move away from the > simple 'experimental' status and dividing it into two - quality rating, and > 'API subject to change' tagging. Does this make sense to anybody else?
As long as an extension can be marked as both, then this certainly sounds like a fine idea. Ilia

Hartmut Holzgraefe

22 years ago
Ilia Alshanetsky wrote:
>>I would like to get some feedback about my suggestion to move away from the >>simple 'experimental' status and dividing it into two - quality rating, and >>'API subject to change' tagging. Does this make sense to anybody else? > > As long as an extension can be marked as both, then this certainly sounds like > a fine idea.
Aren't PECL package version numbers already providing this?
-- Hartmut Holzgraefe <hartmut@php.net>

Derick Rethans

22 years ago
On Fri, 27 Aug 2004, Hartmut Holzgraefe wrote:
> Ilia Alshanetsky wrote: > >>I would like to get some feedback about my suggestion to move away from the > >>simple 'experimental' status and dividing it into two - quality rating, and > >>'API subject to change' tagging. Does this make sense to anybody else? > > > > As long as an extension can be marked as both, then this certainly sounds like > > a fine idea. > > Aren't PECL package version numbers already providing this?
But not everything is in PECL :) Derick
-- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org

Hartmut Holzgraefe

22 years ago
Derick Rethans wrote:
>>Aren't PECL package version numbers already providing this? > > But not everything is in PECL :)
any bundled extensions that are still EXPERIMENTAL should move to PECL anyway IMHO
-- Hartmut Holzgraefe <hartmut@php.net>

Ilia A.

22 years ago
On August 27, 2004 11:31 am, Hartmut Holzgraefe wrote:
> Derick Rethans wrote: > >>Aren't PECL package version numbers already providing this? > > > > But not everything is in PECL :) > > any bundled extensions that are still EXPERIMENTAL should > move to PECL anyway IMHO
+1 Ilia

Zeev Suraski

22 years ago
At 18:33 27/08/2004, Ilia Alshanetsky wrote:
>On August 27, 2004 11:31 am, Hartmut Holzgraefe wrote: > > Derick Rethans wrote: > > >>Aren't PECL package version numbers already providing this? > > > > > > But not everything is in PECL :) > > > > any bundled extensions that are still EXPERIMENTAL should > > move to PECL anyway IMHO > >+1
-1. I think that only extensions whose API is subject to change should be 'banned' from being a part of the standard release. Core extensions, with stable APIs, that just didn't get enough testing (e.g. SOAP, DOM or XSL, at least I think that's the case) can & should stay bundled IMHO. Zeev

Christian Stocker

22 years ago
On 27.8.2004 20:23 Uhr, Zeev Suraski wrote:
> At 18:33 27/08/2004, Ilia Alshanetsky wrote: > >> On August 27, 2004 11:31 am, Hartmut Holzgraefe wrote: >> > Derick Rethans wrote: >> > >>Aren't PECL package version numbers already providing this? >> > > >> > > But not everything is in PECL :) >> > >> > any bundled extensions that are still EXPERIMENTAL should >> > move to PECL anyway IMHO >> >> +1 > > > -1. > > I think that only extensions whose API is subject to change should be > 'banned' from being a part of the standard release. Core extensions, > with stable APIs, that just didn't get enough testing (e.g. SOAP, DOM or > XSL, at least I think that's the case) can & should stay bundled IMHO.
I knew it, that this will stay in the head of people ;) XSL and DOM are not experimental anymore (as already mentioned in another mail in the infamous "flame" thread yesterday). We forgot to remove the EXPERIMENTAL file in CVS, but did that recently. It was always intented to marked as stable for 5.0.0. There's no API to change anyway, as long as the w3c doesn't change it, at least ;) chregu
-- christian stocker | Bitflux GmbH | schoeneggstrasse 5 | ch-8004 zurich phone +41 1 240 56 70 | mobile +41 76 561 88 60 | fax +41 1 240 56 71 http://www.bitflux.ch | chregu@bitflux.ch | gnupg-keyid 0x5CE1DECB

Jason Garber

22 years ago
Hello Zeev, Makes sense to me.
-- Best regards, Jason mailto:jason@ionzoft.com Friday, August 27, 2004, 3:26:25 AM, you wrote: ZS> I would like to get some feedback about my suggestion to move away from the ZS> simple 'experimental' status and dividing it into two - quality rating, and ZS> 'API subject to change' tagging. Does this make sense to anybody else? ZS> Zeev

Wez Furlong

22 years ago
IMO, it makes sense to fold EXPERIMENTAL and CREDITS files into the package.xml files that Hartmut added; they provide versioning and status information. Non-BC API changes require a bump to the API major number; a new major in alpha or beta implies that the new API is subject to change until it is marked stable. --Wez. On Fri, 27 Aug 2004 10:26:25 +0300, Zeev Suraski <zeev@zend.com> wrote: