Re: PECL versioning
| From: | Pierre Joye | Date: | Thu, 20 Mar 2008 01:04:35 +0000 |
| Subject: | Re: PECL versioning | ||
| References: | 1 2 3 4 5 6 7 8 9 10 | Groups: | php.pecl.dev |
| Request: | Send a blank email to pecl-dev+get-5192@lists.php.net to get a copy of this message | ||
Hi,
On Thu, Mar 20, 2008 at 1:55 AM, Steph Fox <steph@zend.com> wrote:
> > This is exactly what we are discussing since months (if not years...)
> > too and what the proposal described. I'm happy to see that you finally
> > understood that working with cvs only is not the way :)
>
> Pierre, that's exactly what I mean by 'fighting me'.
It is not fighiting, it is about exchanging opinions, ideas, thoughts,
plans. Please understand the difference, for my own sanity.
> I didn't 'finally understand' it, I proposed it, and now I'm actually
> working on it.
Ok, do you think that wasting yet more precious tme and resource
instead of actually discussing it, write specs, have a plan is the way
to go? Please take a little break to cool down and try to think about
the benefits of a work in common instead of going in two separate
ways.
> >> If this part goes well it becomes possible to start looking at
> >> the rest, but at present (I think you'd agree) PECL is total anarchy..
> >> and
> >> it's not possible to do anything complicated when there's no underlying
> >> common structure. So basically we need to find a way to implement a
> >> common
> >> structure and make sure all PECL packages adhere to it. The package.xml
> >> file
> >> already does this for package releases, but not for anything else...
> >
> > Everything can be done from the package releases, fetched from
> > http://pecl.php.net .
>
> This is exactly where you're wrong. That's why I wrote to pecl-dev. I can't
> sanely rewrite a small chunk of the core build system to act differently
> depending on whether the package is a release or a snap, it needs to be the
> same for both. The version info for either kind of build needs to come from
> the same place.
It is possible, it works well with my tests while not being ready to
be moved at a production stage. But talking about the DLL info (the rc
data), it is really not the problem or what is the goal to fix that
prior to anything else?
> You really should read the rest of that proposal...
Put it in the wiki, let us discuss and improve it, and finally agree
on something. That's how it should be done imo.
Cheers,
--
Pierre
http://blog.thepimp.net | http://www.libgd.org