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 i
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 extension
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 t
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
--
PHP Interna
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 <[EMAIL PROTECTED]>
--
PHP Internals - PHP Runtime Development Mailing List
To
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 any
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
Hello Zeev,
Makes sense to me.
--
Best regards,
Jasonmailto:[EMAIL PROTECTED]
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 tw
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 a
On Fri, 27 Aug 2004 09:11:58 +0200, Sebastian Bergmann
<[EMAIL PROTECTED]> 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 ou
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 v
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
> t
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. "compil
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 th
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 PEP
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/
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 issu
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]
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 n
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
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
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 developmen
22 matches
Mail list logo
