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 o
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 ho
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 DL
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
> >
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 build
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 c
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 tal
On Mon, Mar 24, 2008 at 11:10 PM, Steph Fox <[EMAIL PROTECTED]> wrote:
> Hi Pierre,
>
>
> >>
> >> 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
>
Hi Pierre,
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 used for
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
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 unsubs
> 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 c
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 sayi
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 extens
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
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
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 t
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
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
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 j
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
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 ha
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/peclversi
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 p
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 they'r
25 matches
Mail list logo
