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. 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? PHP
snapshots or PECL snapshots? releases builds?


>  >>  I also build from CVS, Pierre. It's useful to me to be able to pull out
>  >>  PHP-branch-specific PECL modules from time to time.
>  >
>  > Yes, but what does that have to do with this RFC (versionning) and the
>  > build based on releases instead of CVS?
>
>  What on earth are you talking about? I wasn't talking about *release*
>  versioning, this RFC is for *all* versioning.
>
>  You should have the option for PECL development not to affect the existing
>  users of your package, or to have different releases for different versions
>  of PHP (which some - many - PECL devs will need when we look at PHP 6). If
>  you have a PECL module symlinked into PHP 5.3 and PHP 6.0 they will be
>  slightly different versions, and the way things are set up now there is no
>  way to reflect that difference in the module versioning.

That's why I asked what you are referring to... snapshots, releases,
PHP snapshots, etc. Now it seems that you are talking about PECL
snapshots.

I don't think it is important if a package is symlinked or not. If a
package is in PHP (symlinked, separate module or merge at packaging
time), then it will be available in PHP snapshots anyway.

>  > For the snapshots, I think we can post post pone the discussions and
>  > continue to use what we have in pecl4win (which uses the same branches
>  > than PHP).
>
>  You obviously haven't looked at the source, because pecl4win doesn't use any
>  PECL branches at all.

It does or was supposed to last times Edin discussed it. There was a
set of branches to be used for each PHP version, but I did not check
the code lately.

>  > More generally, this RFC is about versionning and package states as
>  > large. Can we try to finish it then you can finally do your manual
>  > builds at wish. The rest really requires more time and tweaks :)
>
>  I think you should stop coming out with superior or derogatory comments and
>  blocking my attempts to make minor headway in this mess, and try instead to
>  concentrate on helping build a system that has some chance of working. Soon.

Excuse me? What is the problem again? Can you try to stay cool?

>From the very begining you defined what you like to do right now
(after having made some clarifications):

1. Provide DLL per active branche
2. add version info in these DLLs

The 2nd point is why you have created the RFC. That's what we should
try to finish this dicussion and the RFC. For the 1st point you
clearly said that you want it simple and easy as a first step, I
hardly follow you right now as you move in every direction about every
single need of PECL. And that's exactly what I was trying to avoid,
not to block a good move or innovations, but to avoid a chaotic move
in many direction without any specs. Please don't take this last
sentence badly, it is also valid for me.

The problem is that it is very easy in such discussions to be
distracted by other topics and forget the initial RFC (versionning).
If we don't focus on it and your initial goal, we will waste energy
and time to discuss things again and again without any actual results.

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 try to stay on the topic.

Thanks for your understanding,
-- 
Pierre
http://blog.thepimp.net | http://www.libgd.org

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to