hi,
Just a head up here:
http://news.php.net/php.pecl.dev/11879
Please reply there if interested :)
Cheers,
Pierre
@pierrejoye | http://www.libgd.org
Just a head up here:
http://news.php.net/php.pecl.dev/11879
A few things (posting here, as I think it fits the RFC and I am also not
subscribed there)
- this is supposed to be in core, right? The distros often have a
"php-pear" package. How will this work? - how is the symfony stuff gonna be bundled? In a phar? Can we even
include it in the main php release with the symfony license? - I am unsure how composer comes into play here? Needed? Bundled? (Again
I am just trying to grasp what will be needed for an end user to use it) - did you forget to commit pickle/src/Installer.php or is it just not
yet finished? Would be the most interesting part ;) - A bit unsure about the .gitignore part. People might want to configure
that? - Very surprised by renaming CHANGELOG to RELEASE-*, the former is kind
of a standard, why change it? Especially having n files instead of 1.
Apart from that it sounds like a good idea.
~Florian
hi Florian,
Just a head up here:
http://news.php.net/php.pecl.dev/11879A few things (posting here, as I think it fits the RFC and I am also not
subscribed there)
- this is supposed to be in core, right?
pickle.phar, on release yes.
The distros often have a
"php-pear" package. How will this work?
Well, users can still rely on it but mid/long term we will stop
support the pecl command from PEAR.
- how is the symfony stuff gonna be bundled? In a phar?
Yes, see the githug repo.
Can we even
include it in the main php release with the symfony license?
Yes, totally valid license. MIT license.
- I am unsure how composer comes into play here?
Needed?
No, except if you install pickle from the repository.
Bundled?
no, but composer will use pickle.
- did you forget to commit pickle/src/Installer.php or is it just not
yet finished? Would be the most interesting part ;)
That's the easy part :) I am finishing the porting.
The interesting parts are more the packaging, install from git URL,
local check out, conversion from package.xml, etc. They are the hard
part.
Install is easy, except the binary support for windows.
- A bit unsure about the .gitignore part. People might want to configure
that?
We can an option then, but right now that's the most common cases.
- 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.
Apart from that it sounds like a good idea.
Thanks :) Contribs/help welcome :))
Cheers,
Pierre
@pierrejoye | http://www.libgd.org
- 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?
Anyway, this project is great idea. PECL will enter XXI century and it's
great to hear that news. Good luck!
Regards,
Maciej.
- 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