Steph Fox wrote:
I discovered tonight that I have full PECL karma, so the secondary
question is: does anyone have any objection to my making all (or most...
I'd leave the package.xml ones for now) PECL modules fit this versioning
model?
i'm fine with it, and i already changed pecl-gen /
Pierre Joye wrote:
Not
sure if the rest affects codegen, do you check the version format
itself or do you realy on the pear installer for this task?
it is not checked yet, but it is an open TODO item anyway ...
--
Hartmut Holzgraefe, Principal Support Engineer
.
Discover new
On Tue, Mar 25, 2008 at 2:13 AM, Steph Fox [EMAIL PROTECTED] wrote:
You can checkout pecl module branch PHP_5_2 and see all the symlinked
extensions there for PHP_5_2, plus intl...
I know that but that does not tell me what you are talking about now.
OK you lost me completely.
On Tue, Mar 25, 2008 at 10:44 AM, Hartmut Holzgraefe [EMAIL PROTECTED] wrote:
Steph Fox wrote:
I discovered tonight that I have full PECL karma, so the secondary
question is: does anyone have any objection to my making all (or most...
I'd leave the package.xml ones for now) PECL modules
Hi Pierre,
OK you lost me completely. You would rather have no version capability
in
PECL beyond the module itself? What's so confusing about 'if you have
PECL
code that is specific to PHP 6 use the PHP_6_0 branch in PECL'?
I still have no idea what you are talking about. For which
Hi Hartmut,
I discovered tonight that I have full PECL karma, so the secondary
question is: does anyone have any objection to my making all (or most...
I'd leave the package.xml ones for now) PECL modules fit this versioning
model?
i'm fine with it, and i already changed pecl-gen /
On Tue, Mar 25, 2008 at 3:59 PM, Steph Fox [EMAIL PROTECTED] wrote:
I'm sorry if you taken any of my answers badly or personally, none of
them was meant to hurt you or your ideas. It is a discussion about a
RFC and I try to understand what you are asking or discussing. I also
hardly
Hi Pierre,
About the build themselves (and only the builds, versionning problem
is solved, almost), I really need to know what you are going to do. I
know that you will provide DLLs but I don't really know how, where and
from which sources. Am I right that all you want to do now is to
provide
On Tue, Mar 25, 2008 at 4:33 PM, Steph Fox [EMAIL PROTECTED] wrote:
Hi Pierre,
About the build themselves (and only the builds, versionning problem
is solved, almost), I really need to know what you are going to do. I
know that you will provide DLLs but I don't really know how, where
Hi Pierre,
I'll put up another RFC before I make any moves other than those already
discussed. Since I know how now an' all.
For anything related to builds (outside your immediate needs for
manual builds of PECL releases for each PHP release), please hang your
horses. I have began to write
On Sun, Mar 23, 2008 at 3:51 AM, Steph Fox [EMAIL PROTECTED] wrote:
Hi all,
Since I'm still awake at 3am...
Aside from Pierre's arguments in favour of using package.xml to set the
extension version (which 3 PECL extensions - two of them Pierre's - do at
present), does anyone have any
Hello Pierre,
Aside from Pierre's arguments in favour of using package.xml to set the
extension version (which 3 PECL extensions - two of them Pierre's - do
at
present), does anyone have any objection to the proposal at
http://wiki.php.net/rfc/peclversioning?
I'm not in favour of using
Steph Fox wrote:
Hello Pierre,
Aside from Pierre's arguments in favour of using package.xml to set the
extension version (which 3 PECL extensions - two of them Pierre's -
do at
present), does anyone have any objection to the proposal at
http://wiki.php.net/rfc/peclversioning?
I'm not
Hi Steph,
On Mon, Mar 24, 2008 at 3:08 PM, Steph Fox [EMAIL PROTECTED] wrote:
Hello Pierre,
Aside from Pierre's arguments in favour of using package.xml to set the
extension version (which 3 PECL extensions - two of them Pierre's - do
at
present), does anyone have any objection
Hi Pierre...
interest (this last mostly for hosting companies) and some kind of
grading
system. But this is all open to discussion and probably won't happen for
a
long while.
I agree with Greg, only the basic info (what we have now) belongs there.
Apparently there are technical reasons
On Mon, Mar 24, 2008 at 6:05 PM, Steph Fox [EMAIL PROTECTED] wrote:
We already have three sets of rules for that (PEAR rules, php-src rules,
version_compare() rules). Basically if version_compare() can deal with
it,
it's in - I don't see how any other approach can be justified,
re,
On Mon, Mar 24, 2008 at 7:05 PM, Steph Fox [EMAIL PROTECTED] wrote:
Yes, it is what we call the common sense. However it would be even
better to document this common sense so packager (linux distros), new
developers and users will know it.
Yes, that's the plan. But, one thing at
Oooh
What a horrible name :) How about pecl_graveyard?
or siberia? :)
- Steph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi Pierre,
Yes, it is what we call the common sense. However it would be even
better to document this common sense so packager (linux distros), new
developers and users will know it.
Yes, that's the plan. But, one thing at a time...
OK, here's a plan. How about we allow 'core' as a version
Steph Fox wrote:
Oooh
What a horrible name :) How about pecl_graveyard?
or siberia? :)
- Steph
I vote Siberia - after all that's been the joke all along...
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Steph Fox wrote:
What a horrible name :) How about pecl_graveyard?
siberia
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hannes Magnusson wrote:
On Sun, Mar 23, 2008 at 3:51 AM, Steph Fox [EMAIL PROTECTED] wrote:
does anyone have any objection to the proposal at
http://wiki.php.net/rfc/peclversioning?
The first step in fixing the core-pecl relationship? \o/
Looks good.
But what about extensions that are
Re,
will be maintained only there means that no more PECL releases will
be done. In this case, a notice should be added to tell the users to
do not update or use the pecl package anymore (if they use a younger
php version than the one where the extension was bundled).
I hear what you're
The real problem we have is that there's no obvious way to tell if a PECL
package *release* is geared to a specific branch - and that's only really a
problem because we effectively have two development branches in PHP at
present, HEAD and 5_3. Even so, most PECL devs aim to have their code
We have an easy way to do it for released packages, using package.xml.
That's why the PHP version dependency exists.
Please read the rest of my post :)
- Steph
Cheers,
--
Pierre
http://blog.thepimp.net | http://www.libgd.org
--
PHP Internals - PHP Runtime Development Mailing List
To
Hi,
On Mon, Mar 24, 2008 at 10:00 PM, Steph Fox [EMAIL PROTECTED] wrote:
Re,
will be maintained only there means that no more PECL releases will
be done. In this case, a notice should be added to tell the users to
do not update or use the pecl package anymore (if they use a younger
Hi Pierre,
quote
The only problem is for the snapshots, which
version-dev should we use? My plan was to let the developers define
which branch matches which version (like MYEXT_1_8 for 1.8-dev for
example). It should be also possible to let the developers define
which branch should be
On Mon, Mar 24, 2008 at 11:10 PM, Steph Fox [EMAIL PROTECTED] wrote:
Hi Pierre,
quote
The only problem is for the snapshots, which
version-dev should we use? My plan was to let the developers define
which branch matches which version (like MYEXT_1_8 for 1.8-dev for
example).
Hi Pierre,
Now I'm a bit confused. What are yout talking about now? PHP snapshots
or PECL snapshots? releases builds?
You can checkout pecl module branch PHP_5_2 and see all the symlinked
extensions there for PHP_5_2, plus intl...
I know that but that does not tell me what you are
On Sun, Mar 23, 2008 at 3:51 AM, Steph Fox [EMAIL PROTECTED] wrote:
does anyone have any objection to the proposal at
http://wiki.php.net/rfc/peclversioning?
The first step in fixing the core-pecl relationship? \o/
Looks good.
But what about extensions that are symlinked to core? Will they
Hi,
On Sun, 2008-03-23 at 13:01 +0100, Hannes Magnusson wrote:
On Sun, Mar 23, 2008 at 3:51 AM, Steph Fox [EMAIL PROTECTED] wrote:
does anyone have any objection to the proposal at
http://wiki.php.net/rfc/peclversioning?
The first step in fixing the core-pecl relationship? \o/
Looks
Hi,
The first step in fixing the core-pecl relationship? \o/
That's the basic idea, yes.
But what about extensions that are symlinked to core? Will they need
to update their version info during core release cycles?
It obviously shouldn't have a -dev version when distributed with PHP..
Is it
On Sun, Mar 23, 2008 at 2:34 PM, Steph Fox [EMAIL PROTECTED] wrote:
Hi,
The first step in fixing the core-pecl relationship? \o/
That's the basic idea, yes.
But what about extensions that are symlinked to core? Will they need
to update their version info during core release
Exactly. So lets deal with one problem at a time Johannes.
But Steph: Your RFC doesn't mention how to deal with the problem.
During development the extension should be -dev... so who is
responsible to change it back during PHP releases?
Most of the core extensions aren't PECL symlinks, so
OK..
Just removing the -dev in the version number would be wrong (as is
symlinking), a Stable PHP release should include stable extensions.
Not dev versions of the extension. So one of the ideas is to fetch the
last stable extension release for a PHP release, but well, then there's
the problem
35 matches
Mail list logo
