Newsgroups: php.internals,php.pecl.dev
Path: news.php.net
Xref: news.php.net php.internals:36468 php.pecl.dev:5291
Return-Path: <pierre.php@gmail.com>
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 94764 invoked from network); 25 Mar 2008 00:07:31 -0000
Received: from unknown (HELO lists.php.net) (127.0.0.1)
  by localhost with SMTP; 25 Mar 2008 00:07:31 -0000
Authentication-Results: pb1.pair.com smtp.mail=pierre.php@gmail.com; spf=pass; sender-id=pass
Authentication-Results: pb1.pair.com header.from=pierre.php@gmail.com; sender-id=pass; domainkeys=bad
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 66.249.82.238 as permitted sender)
DomainKey-Status: bad
X-DomainKeys: Ecelerity dk_validate implementing draft-delany-domainkeys-base-01
X-PHP-List-Original-Sender: pierre.php@gmail.com
X-Host-Fingerprint: 66.249.82.238 wx-out-0506.google.com  
Received: from [66.249.82.238] ([66.249.82.238:20844] helo=wx-out-0506.google.com)
	by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP
	id BF/EE-20329-14248E74 for <internals@lists.php.net>; Mon, 24 Mar 2008 19:07:30 -0500
Received: by wx-out-0506.google.com with SMTP id s14so3264109wxc.26
        for <internals@lists.php.net>; Mon, 24 Mar 2008 17:07:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=beta;
        h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        bh=sYXdlesyyc+hZ5V/kyoNL8bgzVVahX5qcCNmZMImy9M=;
        b=b236z0dpUXB5pC7Gi+kWoEcf8eEM5r1F2pPcLqoa9Ejc48/okmOcNIfBfnTm7PpjCYl7DAu31X+kVo5hM35lzUOWlt7Kp425GpYUMIqaYRfjtlKqQ9aFkUoGnUlBqwzaolfyLd0JEWFnex8CQ3Z6jclVAiIfFxt1crflohlndvQ=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=e0I5tVatVXa5TqwsAp9c61T9zTy85KPu2wnMSAlHr6jeXMfkTDATc9ui9oTgi365vQyT06dTSa1rqtgPw/y+YvmpMbykJaqkpi6LZsjd8Vg7ttZJ4Mp1JlF+/4DBL5fc6qLssZpW4IdoDp1zJ8NYLLJwyxaFhNux7UypbEQmOdI=
Received: by 10.141.163.12 with SMTP id q12mr2732814rvo.265.1206403646243;
        Mon, 24 Mar 2008 17:07:26 -0700 (PDT)
Received: by 10.141.123.13 with HTTP; Mon, 24 Mar 2008 17:07:26 -0700 (PDT)
Message-ID: <fe05d1540803241707q264b43a9udbdc09c19999d1ac@mail.gmail.com>
Date: Tue, 25 Mar 2008 01:07:26 +0100
To: "Steph Fox" <steph@zend.com>
Cc: pecl-dev@lists.php.net, internals <internals@lists.php.net>
In-Reply-To: <029a01c88dfb$ec131380$c6fc1f3e@foxbox>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <00dc01c88c90$c34c5cc0$c6fc1f3e@foxbox>
	 <003701c88db8$915a4410$c6fc1f3e@foxbox>
	 <fe05d1540803240914u1e36be73hd1730d83c719ce3b@mail.gmail.com>
	 <017901c88dd1$39eb43a0$c6fc1f3e@foxbox>
	 <fe05d1540803241025h5ef7180we0b771af17b4004b@mail.gmail.com>
	 <01cf01c88dd9$b04e99e0$c6fc1f3e@foxbox>
	 <fe05d1540803241123y66d99f27u2658609897eb5728@mail.gmail.com>
	 <024c01c88df2$2aadbb90$c6fc1f3e@foxbox>
	 <fe05d1540803241449m7fa40e7dvf9f8e66b2e325567@mail.gmail.com>
	 <029a01c88dfb$ec131380$c6fc1f3e@foxbox>
Subject: Re: [PHP-DEV] Re: [PECL-DEV] About that PECL versioning thing
From: pierre.php@gmail.com ("Pierre Joye")

On Mon, Mar 24, 2008 at 11:10 PM, Steph Fox <steph@zend.com> 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). It should be also possible to let the developers define
>  >>  which branch should be used for which php versions for the snapshots.
>  >>  </quote>
>  >>
>  >>  I know where you're coming from, but IMHO it would make much more sense
>  >> to
>  >>  use the existing PHP_*_* branches where the package code is *specific*
>  >> to a
>  >>  PHP version. There's no good way for the snaps machine to know about
>  >> 200+
>  >>  different variations on MYEXT_1_8, and likewise there would also be no
>  >> good
>  >>  way for a cvs client to grab all the packages for a given PHP branch out
>  >> of
>  >>  CVS if everyone used differently-named branches to mean that.
>  >
>  > 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 talking about now.


>  > I can answer to the rest of your post once I know better what you are
>  > referring to. I fear that you are making too strong relations between
>  > pecl's cvs and PHP's cvs.
>
>  I think you just haven't stumbled across that co possibility. It doesn't
>  show up anywhere as an official PECL branch, but it does work.

Again, CVS should be used only for snaphots nothing else. But I don't
know what you are referring to.


>  > As I can understand that one may like to have the same branches, I
>  > don't want to have to use them. PHP branches do not fit well to pecl
>  > development, as you noticed already almost all packages can be built
>  > against all php versions. The goal is to have a stable branch and
>  > maybe some expiremental branches (they are not really relevant in your
>  > case, build a dll for each active PHP branch).
>
>  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?

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).

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 :)

Cheersm
-- 
Pierre
http://blog.thepimp.net | http://www.libgd.org