Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:74876
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.174 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <44.74.02977.E15A9935@pb1.pair.com>
References: <CAEZPtU79f8bFdxXU5dEShf31ifz5N6hiLJeRgv6ik3GxSajP5w@mail.gmail.com>
	<5398D872.2060805@anderiasch.de>
	<CAEZPtU52jn562ncGXw1zBi4ouGrMGSmsUrDv0D1oP5=wXjOGQA@mail.gmail.com>
	<44.74.02977.E15A9935@pb1.pair.com>
Date: Thu, 12 Jun 2014 17:09:30 +0200
Message-ID: <CAEZPtU7rgKy+zp2qVujOGy9rr61N-rzRxkD0hy92Z+eN0p8+0A@mail.gmail.com>
To: Maciej Sobaczewski <sobak@php.net>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] head up: New extension installer in dev
From: pierre.php@gmail.com (Pierre Joye)

On Thu, Jun 12, 2014 at 3:03 PM, Maciej Sobaczewski <sobak@php.net> wrote:
>>> - Very surprised by renaming CHANGELOG to RELEASE-*, the former is kind
>>> of a standard, why change it? Especially having n files instead of 1.
>>
>>
>> because it is not a commit changelog but the equivalent of what we
>> find in the package.xml release notes (or in the pecl.php.net page
>> about a release). Naming are only names, it can be changed very
>> easily.
>>
>
> In my opinion name isn't a big problem. However, I agree with Florian that
> requiring many files instead of one, will lead to mess. Couldn't we use some
> syntax to put it in one file?

That's what we have now with the package.xml and it is painful to
maintain. Also the information are duplicated between the package.xml
and the various other files (source code, config.*, etc.). What pickle
does now is to fetch the information where it is available already and
add them to the json file. I am adding the code to fetch the configure
options automatically from config.m4 and w32, which are very out of
sync, between config&package.xml, f.e.

 Also one single file could bring some issue for composer (not for
pickle itself, which will be mainly used in a standalone way by
developers), especially for all the changelog related information.
What I propose here is to have one file per release, put all the info
you like in it and that's it. pecl.php.net will use it when an user
looks at one specific release (markdown will be supported f.e.).


> Anyway, this project is great idea. PECL will enter XXI century and it's
> great to hear that news. Good luck!

Thanks! Contrib welcome :)

Cheers,
-- 
Pierre

@pierrejoye | http://www.libgd.org