Hi all,
Since I'm still awake at 3am...
Aside from Pierre's arguments in favour of using package.xml to set the
extension version (which 3 PECL extensions - two of them Pierre's - do at
present), does anyone have any objection to the proposal at
http://wiki.php.net/rfc/peclversioning?
I discovered tonight that I have full PECL karma, so the secondary question
is: does anyone have any objection to my making all (or most... I'd leave
the package.xml ones for now) PECL modules fit this versioning model?
- Steph
does anyone have any objection to the proposal at
http://wiki.php.net/rfc/peclversioning?
The first step in fixing the core<->pecl relationship? \o/
Looks good.
But what about extensions that are symlinked to core? Will they need
to update their version info during core release cycles?
It obviously shouldn't have a -dev version when distributed with PHP..
Is it up to the RM to hunt those extensions down and make sure the
version info is accurate?
-Hannes
Hi,
does anyone have any objection to the proposal at
http://wiki.php.net/rfc/peclversioning?The first step in fixing the core<->pecl relationship? \o/
Looks good.
But what about extensions that are symlinked to core? Will they need
to update their version info during core release cycles?
It obviously shouldn't have a -dev version when distributed with PHP..
Is it up to the RM to hunt those extensions down and make sure the
version info is accurate?
Just removing the "-dev" in the version number would be wrong (as is
symlinking), a Stable PHP release should include "stable" extensions.
Not dev versions of the extension. So one of the ideas is to fetch the
last stable extension release for a PHP release, but well, then there's
the problem that everybody (people using snaps, people using CVS, ...)
end up with different versions which makes QA hard. (not to mention bug
hunting trouble with people using the latest release but updated a
single extension, ....)
johannes
Hi,
The first step in fixing the core<->pecl relationship? \o/
That's the basic idea, yes.
But what about extensions that are symlinked to core? Will they need
to update their version info during core release cycles?
It obviously shouldn't have a -dev version when distributed with PHP..
Is it up to the RM to hunt those extensions down and make sure the
version info is accurate?Just removing the "-dev" in the version number would be wrong (as is
symlinking), a Stable PHP release should include "stable" extensions.
Not dev versions of the extension. So one of the ideas is to fetch the
last stable extension release for a PHP release, but well, then there's
the problem that everybody (people using snaps, people using CVS, ...)
end up with different versions which makes QA hard. (not to mention bug
hunting trouble with people using the latest release but updated a
single extension, ....)
But we already have those problems now. Labelling the version just makes it
more obvious that we have those problems :)
- Steph
johannes
Hi,
The first step in fixing the core<->pecl relationship? \o/
That's the basic idea, yes.
But what about extensions that are symlinked to core? Will they need
to update their version info during core release cycles?
It obviously shouldn't have a -dev version when distributed with PHP..
Is it up to the RM to hunt those extensions down and make sure the
version info is accurate?Just removing the "-dev" in the version number would be wrong (as is
symlinking), a Stable PHP release should include "stable" extensions.
Not dev versions of the extension. So one of the ideas is to fetch the
last stable extension release for a PHP release, but well, then there's
the problem that everybody (people using snaps, people using CVS, ...)
end up with different versions which makes QA hard. (not to mention bug
hunting trouble with people using the latest release but updated a
single extension, ....)But we already have those problems now. Labelling the version just makes it
more obvious that we have those problems :)
Exactly. So lets deal with one problem at a time Johannes.
But Steph: Your RFC doesn't mention how to deal with the problem.
During development the extension should be -dev... so who is
responsible to change it back during PHP releases?
-Hannes
Exactly. So lets deal with one problem at a time Johannes.
But Steph: Your RFC doesn't mention how to deal with the problem.
During development the extension should be -dev... so who is
responsible to change it back during PHP releases?
Most of the core extensions aren't PECL symlinks, so they're not a problem
for now - they can use PHP's own versioning while they're in the mothership,
it makes as much sense as anything.
I'll make a list of the ones that are symlinked... unless someone already
has one? then we can see how much of an issue it is or isn't.
- Steph
-Hannes
OK..
Just removing the "-dev" in the version number would be wrong (as is
symlinking), a Stable PHP release should include "stable" extensions.
Not dev versions of the extension. So one of the ideas is to fetch the
last stable extension release for a PHP release, but well, then there's
the problem that everybody (people using snaps, people using CVS, ...)
end up with different versions which makes QA hard. (not to mention bug
hunting trouble with people using the latest release but updated a
single extension, ....)
Temporary halfway-house solution: don't tag the symlinked extensions
with -dev for now, just call them 1.0.0 or whatever. We can move to proper
versioning for those symlinked ones when we have a way to bring stable PECL
packages into core, but at least there'll be a structure already in place
that makes that easy.
- Steph
johannes
Hannes Magnusson wrote:
does anyone have any objection to the proposal at
http://wiki.php.net/rfc/peclversioning?The first step in fixing the core<->pecl relationship? \o/
Looks good.
But what about extensions that are symlinked to core? Will they need
to update their version info during core release cycles?
The version number should only change if extension code has been
changed. The fact there is a symlink is not really relevent. PHP
will have an issue with any extension at PHP release time if the
extension code is still marked -dev or -beta.
Open question: do we want an extension's version to be the same in its
PHP 5.3 and its PHP 6 code base?
It obviously shouldn't have a -dev version when distributed with PHP..
Is it up to the RM to hunt those extensions down and make sure the
version info is accurate?
I'd suggest so.
Chris
--
Christopher Jones, Oracle
Email: christopher.jones@oracle.com Tel: +1 650 506 8630
Blog: http://blogs.oracle.com/opal/ Free PHP Book: http://tinyurl.com/f8jad
Follow me: http://friendfeed.com/ghrd
Hi all,
Since I'm still awake at 3am...
Aside from Pierre's arguments in favour of using package.xml to set the
extension version (which 3 PECL extensions - two of them Pierre's - do at
present), does anyone have any objection to the proposal at
http://wiki.php.net/rfc/peclversioning?
I'm not in favour of using package.xml to set the version. I'm in
favour of allowing package.xml usage.
Now, why cross posting, adding a random set of the pecl-dev
discussions as comments in the wiki? And the rules about what means a
version increment is missing.
The wiki is a publication media, the lists are the discussion
media.pecl-dev in this case is the right list.
As far as I remember, php-src did not want to have per extension
versions. However, It is fine to add an information about its version
to help the users to know if the pecl releases is newer than the
bundled version. Can we please keep the discussions in on list? It is
already hard enough to follow everything.
I discovered tonight that I have full PECL karma, so the secondary question
is: does anyone have any objection to my making all (or most... I'd leave
the package.xml ones for now) PECL modules fit this versioning model?
Many extensions use branches, I would go with a patch posted to
pecl-dev and let the respective maintainers apply it to the active
branches. (zip has two branches + php-src).
Cheers,
Hello Pierre,
Aside from Pierre's arguments in favour of using package.xml to set the
extension version (which 3 PECL extensions - two of them Pierre's - do
at
present), does anyone have any objection to the proposal at
http://wiki.php.net/rfc/peclversioning?I'm not in favour of using package.xml to set the version. I'm in
favour of allowing package.xml usage.
Nobody's attempting to prevent package.xml usage, least of all me! I
actually want to extend package.xml to give more information (QA related) so
that people have more of a clue about what they're dealing with. E.g. code
coverage %, maintenance status, whether the package is of general/special
interest (this last mostly for hosting companies) and some kind of grading
system. But this is all open to discussion and probably won't happen for a
long while.
Now, why cross posting, adding a random set of the pecl-dev
discussions as comments in the wiki?
Because you told me to do that :) I stopped when it became clear nobody was
going to put comments on there.
And the rules about what means a
version increment is missing.
We already have three sets of rules for that (PEAR rules, php-src rules,
version_compare() rules). Basically if version_compare() can deal with it,
it's in - I don't see how any other approach can be justified, since it may
mean messing up someone's long-adopted system.
As far as I remember, php-src did not want to have per extension
versions.
php-src needs to decide what's core (and takes the PHP version) and what's
not. This isn't going to happen overnight, so I've compromised by not using
the -dev tag for symlinked extensions and by applying the RC data to PECL
builds only. There are a few other packages that won't get a -dev tag
because they haven't been touched since the last (often first) package
release, ie they're not under active development. These aren't necessarily
stable, but that's a whole separate issue... we need a way to clearly mark
orphaned packages, both for pear/pyrus and for pecl.php.net.
However, It is fine to add an information about its version
to help the users to know if the pecl releases is newer than the
bundled version. Can we please keep the discussions in on list? It is
already hard enough to follow everything.
There haven't been any off-list discussions about this... unless you count
my asking permission from various individuals to add versioning to their
packages?
I discovered tonight that I have full PECL karma, so the secondary
question
is: does anyone have any objection to my making all (or most... I'd
leave
the package.xml ones for now) PECL modules fit this versioning model?Many extensions use branches, I would go with a patch posted to
pecl-dev and let the respective maintainers apply it to the active
branches. (zip has two branches + php-src).
This affects 27 symlinked extensions in 5_2 and 21 in 5_3, all of which I
have checked out locally. It's a relative non-issue, for the reasons given
above.
I started work yesterday on extensions where the maintainer has given
explicit permission or where I know for sure they're no longer involved in
PHP development (Sterling, Tal). Amazingly, fribidi still works after five
years of zero interference :)
I'll post patches for the rest on a per-maintainer basis over the coming
weeks, but I have to say there are a number of PECL packages I believe are
long-time orphans.
- Steph
Cheers,
Steph Fox wrote:
Hello Pierre,
Aside from Pierre's arguments in favour of using package.xml to set the
extension version (which 3 PECL extensions - two of them Pierre's -
do at
present), does anyone have any objection to the proposal at
http://wiki.php.net/rfc/peclversioning?I'm not in favour of using package.xml to set the version. I'm in
favour of allowing package.xml usage.Nobody's attempting to prevent package.xml usage, least of all me! I
actually want to extend package.xml to give more information (QA
related) so that people have more of a clue about what they're dealing
with. E.g. code coverage %, maintenance status, whether the package is
of general/special interest (this last mostly for hosting companies) and
some kind of grading system. But this is all open to discussion and
probably won't happen for a long while.
This kind of meta-data doesn't belong in a package.xml, but it would
make perfect sense to host it through REST on pecl.php.net. Don't
forget, package.xml is used by external channels as well, and they have
completely different requirements.
package.xml is intended to be used by the pear installer to install
packages and provide essential metadata only.
Greg
Hi Steph,
Hello Pierre,
Aside from Pierre's arguments in favour of using package.xml to set the
extension version (which 3 PECL extensions - two of them Pierre's - do
at
present), does anyone have any objection to the proposal at
http://wiki.php.net/rfc/peclversioning?I'm not in favour of using package.xml to set the version. I'm in
favour of allowing package.xml usage.Nobody's attempting to prevent package.xml usage, least of all me!
Can you try to read the history? This is a reply to you, when you say
that I'm in favour of using package.xml...
I actually want to extend package.xml to give more information (QA related) so
that people have more of a clue about what they're dealing with. E.g. code
coverage %, maintenance status, whether the package is of general/special
interest (this last mostly for hosting companies) and some kind of grading
system. But this is all open to discussion and probably won't happen for a
long while.
I agree with Greg, only the basic info (what we have now) belongs there.
Now, why cross posting, adding a random set of the pecl-dev
discussions as comments in the wiki?Because you told me to do that :) I stopped when it became clear nobody was
going to put comments on there.
I never told you to do that. Let me try to summarize:
- publish a RFC in the wiki
- announce the publication in one list (if possible only one list :)
- update the RFC according to the discussions, that can include a
section containing "To be discussed/being discussed" entries
Doing so let one jump into the discussions without having to read
dozen of mails on many lists (like now) to get an idea of the current
RFC status :)
And the rules about what means a
version increment is missing.We already have three sets of rules for that (PEAR rules, php-src rules,
version_compare()rules). Basically ifversion_compare()can deal with it,
it's in - I don't see how any other approach can be justified, since it may
mean messing up someone's long-adopted system.
It has nothing to do with version_compare, absolutely nothing. What
I'm saying is only what PEAR already does successfully since years. It
works very well, it is clear and does not allow some random confusing
versions like 0.1.0-stable.
As far as I remember, php-src did not want to have per extension
versions.php-src needs to decide what's core (and takes the PHP version) and what's
not.
Everything being in php-src is core. No matter what we'll do next
month or in 10 years.
This isn't going to happen overnight, so I've compromised by not using
the -dev tag for symlinked extensions and by applying the RC data to PECL
builds only.
That makes little sense to me. If we provide snapshots from PECL, they
should follow the same rules than all other PECL extensions.
If an extension is also available in PHP releases, then the PHP
snapshots will provide it as well for the bundled versions.
There are a few other packages that won't get a -dev tag
because they haven't been touched since the last (often first) package
release, ie they're not under active development.
Well, if a package has not been touched, it won't be built and the old
dll will be kept no?
These aren't necessarily
stable, but that's a whole separate issue... we need a way to clearly mark
orphaned packages, both for pear/pyrus and for pecl.php.net.
PEAR already has a nice system for that, I think we can use it as it
is now. It has been proven to work very well since years.
However, It is fine to add an information about its version
to help the users to know if the pecl releases is newer than the
bundled version. Can we please keep the discussions in on list? It is
already hard enough to follow everything.There haven't been any off-list discussions about this... unless you count
my asking permission from various individuals to add versioning to their
packages?
I'm talking about your post on internals. It is nice to point
internals to the RFC and the pecl-dev discussions though.
I discovered tonight that I have full PECL karma, so the secondary
question
is: does anyone have any objection to my making all (or most... I'd
leave
the package.xml ones for now) PECL modules fit this versioning model?Many extensions use branches, I would go with a patch posted to
pecl-dev and let the respective maintainers apply it to the active
branches. (zip has two branches + php-src).This affects 27 symlinked extensions in 5_2 and 21 in 5_3, all of which I
have checked out locally. It's a relative non-issue, for the reasons given
above.
It is a non issue as the versions available in the dllinfo is not that
useful. But to apply a patch to a set of random branches is not really
a good idea even if it works for many extensions.
I'll post patches for the rest on a per-maintainer basis over the coming
weeks, but I have to say there are a number of PECL packages I believe are
long-time orphans.
Yes, that's a real problem in PECL. One cause was to move dead
extensions from php-src to pecl/ instead of a orphaned repository. It
also affects only CVS users as long as these packages do not have any
pecl.php.net entry (without releases for example). What would be the
best way to deal with dead or orphaned extensions? A separate
extensions for dead extensions and add a file "REAME.ORPHANED" for the
orphaned extension?
That brings me to the next problem (we can discuss it in a separate
RFC :), but for the record:
- dead extension: useless extension like php4 dom or axis (not in pecl anymore)
- orphaned extension: could still be useful but no active maintainer
(for example event)
Cheers,
Hi Pierre...
interest (this last mostly for hosting companies) and some kind of
grading
system. But this is all open to discussion and probably won't happen for
a
long while.I agree with Greg, only the basic info (what we have now) belongs there.
Apparently there are technical reasons for that. This would've come out in
that later discussion, but now we have it as a 'given' before we start...
makes things a little easier for the summer I guess :)
And the rules about what means a
version increment is missing.We already have three sets of rules for that (PEAR rules, php-src rules,
version_compare()rules). Basically ifversion_compare()can deal with
it,
it's in - I don't see how any other approach can be justified, since it
may
mean messing up someone's long-adopted system.It has nothing to do with version_compare, absolutely nothing. What
I'm saying is only what PEAR already does successfully since years. It
works very well, it is clear and does not allow some random confusing
versions like 0.1.0-stable.
Neither does version_compare(). The only problem I've found with it is that
it doesn't recognize 1.0.0 and 1.0 as the same value, but that's only a
problem if you change existing patterns. (Bear in mind that there are
existing patterns for everything that ever had a PECL release, which should
be honoured if the 'pecl' command is to keep working.) Also, I've found
nothing in PECL that deems itself 'stable' at 0.1.0, so I think that's a bit
of a red herring. People seem to have been very good about that on the
whole.
As far as I remember, php-src did not want to have per extension
versions.php-src needs to decide what's core (and takes the PHP version) and
what's
not.Everything being in php-src is core. No matter what we'll do next
month or in 10 years.This isn't going to happen overnight, so I've compromised by not using
the -dev tag for symlinked extensions and by applying the RC data to
PECL
builds only.That makes little sense to me. If we provide snapshots from PECL, they
should follow the same rules than all other PECL extensions.
OK, here's a plan. How about we allow 'core' as a version tag (for use in
MINFO and RC stuff only - package.xml obviously won't use it, and PECL
package releases shouldn't either). So you'd have a version string like
'1.5.0-core' in phpinfo() and in the .dll for core extensions, and in both
cases the PHP version information is also available. A $Revision or $Id
string in MINFO would also be useful in core extensions, purely from the
bug-tracking PoV.
This way you can easily see 1) the package release version, 2) whether or
not it ships with PHP (and which version), and 3) when the code was last
updated. We also avoid Johannes' problem of needing PECL release packages in
a PHP release at a time when this isn't an option.
If an extension is also available in PHP releases, then the PHP
snapshots will provide it as well for the bundled versions.There are a few other packages that won't get a -dev tag
because they haven't been touched since the last (often first) package
release, ie they're not under active development.Well, if a package has not been touched, it won't be built and the old
dll will be kept no?
No. We have new PHP versions every now and again...
These aren't necessarily
stable, but that's a whole separate issue... we need a way to clearly
mark
orphaned packages, both for pear/pyrus and for pecl.php.net.PEAR already has a nice system for that, I think we can use it as it
is now. It has been proven to work very well since years.
Feel free to adapt it to PECL :)
This affects 27 symlinked extensions in 5_2 and 21 in 5_3, all of which
I
have checked out locally. It's a relative non-issue, for the reasons
given
above.It is a non issue as the versions available in the dllinfo is not that
useful. But to apply a patch to a set of random branches is not really
a good idea even if it works for many extensions.
I'm not 'applying a patch to a set of random branches'.... tsk!
I'll post patches for the rest on a per-maintainer basis over the coming
weeks, but I have to say there are a number of PECL packages I believe
are
long-time orphans.Yes, that's a real problem in PECL. One cause was to move dead
extensions from php-src to pecl/ instead of a orphaned repository. It
also affects only CVS users as long as these packages do not have any
pecl.php.net entry (without releases for example). What would be the
best way to deal with dead or orphaned extensions? A separate
extensions for dead extensions and add a file "REAME.ORPHANED" for the
orphaned extension?
I think just ORPHANED, like we already have CREDITS and EXPERIMENTAL.
(Elizabeth will disagree - has already - but I really don't see a better way
of approaching this.)
That brings me to the next problem (we can discuss it in a separate
RFC :), but for the record:
- dead extension: useless extension like php4 dom or axis (not in pecl
anymore)- orphaned extension: could still be useful but no active maintainer
(for example event)
The problem there is that it's not always possible to know the difference.
How do we know if an extension is 'dead', what are the criteria for that?
And should they be removed? (My instinct says 'yes' but thousands may
disagree with me.) Also, who gets to make that decision?
- Steph
Cheers,
We already have three sets of rules for that (PEAR rules, php-src rules,
version_compare()rules). Basically ifversion_compare()can deal with
it,
it's in - I don't see how any other approach can be justified, since it
may
mean messing up someone's long-adopted system.It has nothing to do with version_compare, absolutely nothing. What
I'm saying is only what PEAR already does successfully since years. It
works very well, it is clear and does not allow some random confusing
versions like 0.1.0-stable.Neither does
version_compare(). The only problem I've found with it is that
it doesn't recognize 1.0.0 and 1.0 as the same value,
That's a know issue and that's also why we recommend to use the x.y.z
form and not the x.y short version.
but that's only a
problem if you change existing patterns. (Bear in mind that there are
existing patterns for everything that ever had a PECL release, which should
be honoured if the 'pecl' command is to keep working.) Also, I've found
nothing in PECL that deems itself 'stable' at 0.1.0, so I think that's a bit
of a red herring. People seem to have been very good about that on the
whole.
Yes, it is what we call the common sense. However it would be even
better to document this common sense so packager (linux distros), new
developers and users will know it.
OK, here's a plan. How about we allow 'core' as a version tag (for use in
MINFO and RC stuff only - package.xml obviously won't use it, and PECL
package releases shouldn't either). So you'd have a version string like
'1.5.0-core' inphpinfo()and in the .dll for core extensions, and in both
cases the PHP version information is also available. A $Revision or $Id
string in MINFO would also be useful in core extensions, purely from the
bug-tracking PoV.
This way you can easily see 1) the package release version, 2) whether or
not it ships with PHP (and which version), and 3) when the code was last
updated. We also avoid Johannes' problem of needing PECL release packages in
a PHP release at a time when this isn't an option.
It may do it. $Revision will still be there (as almost every extension
provides it) but it is not very useful (see previous mails).
As a summay, we have the following cases:
- a PECL package is now in core and will be maintained only there.
The PECL homepage has to say it - a PECL package is now in core and will still be maintained in PECL.
For each PHP releases, a PECL release could be done as well so the
versions can be matched - a PECL package is now in core and will still be maintained in PECL.
Core and PECL has two completely different roadmaps, I have no idea
how to actually solve this case :)
We also avoid Johannes' problem of needing PECL release packages in
a PHP release at a time when this isn't an option.
About merging a PECL release in a PHP release at packaging time
(packaging PHP release), if it is possible to detect whether we are
building an extension inside php-src or using phpize (via pecl or
manually) then it would be possible to add the "-core" postfix via a
simple #ifdef (I'll love to do it for zip).
Well, if a package has not been touched, it won't be built and the old
dll will be kept no?No. We have new PHP versions every now and again...
I obviously meant to do not build it again for a given PHP version.
These aren't necessarily
stable, but that's a whole separate issue... we need a way to clearly
mark
orphaned packages, both for pear/pyrus and for pecl.php.net.PEAR already has a nice system for that, I think we can use it as it
is now. It has been proven to work very well since years.Feel free to adapt it to PECL :)
That's what I partially did earlier (x.y.z+1 , x.y+1.z, x+1.y.z). I'll
add the relevant part to the RFC and merge the points we already
agreed on.
It is a non issue as the versions available in the dllinfo is not that
useful. But to apply a patch to a set of random branches is not really
a good idea even if it works for many extensions.I'm not 'applying a patch to a set of random branches'.... tsk!
For example HEAD can be a random branch as well. It was not badly
meant but only a possible source of errors/confusions.
Yes, that's a real problem in PECL. One cause was to move dead
extensions from php-src to pecl/ instead of a orphaned repository. It
also affects only CVS users as long as these packages do not have any
pecl.php.net entry (without releases for example). What would be the
best way to deal with dead or orphaned extensions? A separate
extensions for dead extensions and add a file "REAME.ORPHANED" for the
orphaned extension?I think just ORPHANED, like we already have CREDITS and EXPERIMENTAL.
(Elizabeth will disagree - has already - but I really don't see a better way
of approaching this.)
ORPHANED may do it as well.
That brings me to the next problem (we can discuss it in a separate
RFC :), but for the record:
- dead extension: useless extension like php4 dom or axis (not in pecl
anymore)- orphaned extension: could still be useful but no active maintainer
(for example event)The problem there is that it's not always possible to know the difference.
How do we know if an extension is 'dead', what are the criteria for that?
There is many obvious cases:
- a given extension is hosted somewhere else
- the service used or targeted by the extension does not exist anymore
- the extension is superseded by core features (php4 dom for example)
It has to be discussed on a case by case basis anyway but for the vast
majority, it is rather obvious.
And should they be removed? (My instinct says 'yes' but thousands may
disagree with me.) Also, who gets to make that decision?
Having the code still readable somewhere is a good thing. We can
simply move them in pecldeadext repository.
Cheers,
Hi Pierre,
Yes, it is what we call the common sense. However it would be even
better to document this common sense so packager (linux distros), new
developers and users will know it.
Yes, that's the plan. But, one thing at a time...
OK, here's a plan. How about we allow 'core' as a version tag (for use
in
MINFO and RC stuff only - package.xml obviously won't use it, and PECL
package releases shouldn't either). So you'd have a version string like
'1.5.0-core' inphpinfo()and in the .dll for core extensions, and in
both
cases the PHP version information is also available. A $Revision or $Id
string in MINFO would also be useful in core extensions, purely from the
bug-tracking PoV.
This way you can easily see 1) the package release version, 2) whether
or
not it ships with PHP (and which version), and 3) when the code was last
updated. We also avoid Johannes' problem of needing PECL release
packages in
a PHP release at a time when this isn't an option.It may do it. $Revision will still be there (as almost every extension
provides it) but it is not very useful (see previous mails).
I know, but it gives a bit of a clue in what would otherwise be a void.
As a summay, we have the following cases:
- a PECL package is now in core and will be maintained only there.
The PECL homepage has to say it
This doesn't make a lot of sense to me - if they're symlinked, changes made
in php-src ext/whatever are really going into PECL CVS. There's no reason
there couldn't be a PECL release of a symlinked core package, either (in
fact pecl/hash should probably have one following Solar Designer's patch).
Or do you mean non-symlinked packages? If so, are there any PECL packages
currently in core that are in this situation?
- a PECL package is now in core and will still be maintained in PECL.
For each PHP releases, a PECL release could be done as well so the
versions can be matched
This would be the ideal scenario all round, but enforcing it may be
problematic!
- a PECL package is now in core and will still be maintained in PECL.
Core and PECL has two completely different roadmaps, I have no idea
how to actually solve this case :)
Isn't that what CVS branches are for?
We also avoid Johannes' problem of needing PECL release packages in
a PHP release at a time when this isn't an option.About merging a PECL release in a PHP release at packaging time
(packaging PHP release), if it is possible to detect whether we are
building an extension inside php-src or using phpize (via pecl or
manually) then it would be possible to add the "-core" postfix via a
simple #ifdef (I'll love to do it for zip).
Cool :) For the RC stuff I just checked whether the path to the extension
src included 'pecl' or not.
Well, if a package has not been touched, it won't be built and the old
dll will be kept no?No. We have new PHP versions every now and again...
I obviously meant to do not build it again for a given PHP version.
It doesn't seem to care about mtime anyway, so I was wrong too:
http://cvs.php.net/viewvc.cgi/pecl/fribidi/
http://pecl4win.php.net/ext.php/php_fribidi.dll
These aren't necessarily
stable, but that's a whole separate issue... we need a way to
clearly
mark
orphaned packages, both for pear/pyrus and for pecl.php.net.PEAR already has a nice system for that, I think we can use it as it
is now. It has been proven to work very well since years.Feel free to adapt it to PECL :)
That's what I partially did earlier (x.y.z+1 , x.y+1.z, x+1.y.z). I'll
add the relevant part to the RFC and merge the points we already
agreed on.
Thanks!
It is a non issue as the versions available in the dllinfo is not that
useful. But to apply a patch to a set of random branches is not really
a good idea even if it works for many extensions.I'm not 'applying a patch to a set of random branches'.... tsk!
For example HEAD can be a random branch as well. It was not badly
meant but only a possible source of errors/confusions.
No... it won't be, because in all cases where there is symlinking, all
affected branches of the same extension will have the same version number -
based on the most recent PECL release and tagged with -core. I'm only
looking at 5_2, 5_3 and HEAD here, no more than that.
Yes, that's a real problem in PECL. One cause was to move dead
extensions from php-src to pecl/ instead of a orphaned repository. It
also affects only CVS users as long as these packages do not have any
pecl.php.net entry (without releases for example). What would be the
best way to deal with dead or orphaned extensions? A separate
extensions for dead extensions and add a file "REAME.ORPHANED" for the
orphaned extension?I think just ORPHANED, like we already have CREDITS and EXPERIMENTAL.
(Elizabeth will disagree - has already - but I really don't see a better
way
of approaching this.)ORPHANED may do it as well.
Should I start adding these now, where it's very obvious? And should there
be some note inside the ORPHANED file to say what the extension needs? To go
back to fribidi again (because it's a simple extension that hasn't been
touched in 4 years and I know Tal's not likely to come back to it), there's
a single compiler warning due to snprintf() changes in PHP and no tests at
all. Nothing wrong with the extension itself, it works fine - but it is
orphaned.
That brings me to the next problem (we can discuss it in a separate
RFC :), but for the record:
- dead extension: useless extension like php4 dom or axis (not in pecl
anymore)- orphaned extension: could still be useful but no active maintainer
(for example event)The problem there is that it's not always possible to know the
difference.
How do we know if an extension is 'dead', what are the criteria for
that?There is many obvious cases:
- a given extension is hosted somewhere else
- the service used or targeted by the extension does not exist anymore
- the extension is superseded by core features (php4 dom for example)
It has to be discussed on a case by case basis anyway but for the vast
majority, it is rather obvious.And should they be removed? (My instinct says 'yes' but thousands may
disagree with me.) Also, who gets to make that decision?Having the code still readable somewhere is a good thing. We can
simply move them in pecldeadext repository.
What a horrible name :) How about pecl_graveyard?
- Steph
Cheers,
re,
Yes, it is what we call the common sense. However it would be even
better to document this common sense so packager (linux distros), new
developers and users will know it.Yes, that's the plan. But, one thing at a time...
The "versionning" RFC is the perfect place to describe ... versions :)
As a summay, we have the following cases:
- a PECL package is now in core and will be maintained only there.
The PECL homepage has to say itThis doesn't make a lot of sense to me - if they're symlinked, changes made
in php-src ext/whatever are really going into PECL CVS.
"will be maintained only there" means that no more PECL releases will
be done. In this case, a notice should be added to tell the users to
do not update or use the pecl package anymore (if they use a younger
php version than the one where the extension was bundled).
There's no reason
there couldn't be a PECL release of a symlinked core package, either (in
fact pecl/hash should probably have one following Solar Designer's patch).
Or do you mean non-symlinked packages? If so, are there any PECL packages
currently in core that are in this situation?
It is not about how the CVS works or if it is used at all but if there
will have PECL releases or not once the extension is bundled. For the
record, what we have (or plan to) now is:
- symlink, common case, what we historically did and do
- duplicated, how zip works, php-src/ext/zip is a module and is
unrelated to pecl/zip, one has to commit to both tree - merge at release time, how phar may work as far as I remember
(that's actually my favourite one as it allows one to work only in
pecl and does not care too much about php releases in his development)
- a PECL package is now in core and will still be maintained in PECL.
For each PHP releases, a PECL release could be done as well so the
versions can be matchedThis would be the ideal scenario all round, but enforcing it may be
problematic!
That's scenarii, not something I like to enforce, only an enumaration
of existing cases :)
- a PECL package is now in core and will still be maintained in PECL.
Core and PECL has two completely different roadmaps, I have no idea
how to actually solve this case :)Isn't that what CVS branches are for?
Yes, and how do you define which branch maps to which version? (See my
very first reply for a solution, we can do that later :)
Well, if a package has not been touched, it won't be built and the old
dll will be kept no?No. We have new PHP versions every now and again...
I obviously meant to do not build it again for a given PHP version.
It doesn't seem to care about mtime anyway, so I was wrong too:
http://cvs.php.net/viewvc.cgi/pecl/fribidi/
http://pecl4win.php.net/ext.php/php_fribidi.dll
It can be solved later for the snapshots, for the release it is rather
easy to do :)
For example HEAD can be a random branch as well. It was not badly
meant but only a possible source of errors/confusions.No... it won't be, because in all cases where there is symlinking, all
affected branches of the same extension will have the same version number -
based on the most recent PECL release and tagged with -core. I'm only
looking at 5_2, 5_3 and HEAD here, no more than that.
I'm not sure to understand what you mean. Do you mean that all
affected branches will have the same version like all branches (5.x or
HEAD) will have the same version?
Or do you mean that each branch can have a version?
The later makes more sense to me. I can imagine a 2.x version for HEAD
and still having 1.x for 5.x
I think just ORPHANED, like we already have CREDITS and EXPERIMENTAL.
(Elizabeth will disagree - has already - but I really don't see a better
way
of approaching this.)ORPHANED may do it as well.
Should I start adding these now, where it's very obvious? And should there
be some note inside the ORPHANED file to say what the extension needs?
Can you post a list in the wiki or to the list so we can validate it first?
What a horrible name :) How about pecl_graveyard?
Whatever we like as long as it is well documented :)
Cheers,
Re,
"will be maintained only there" means that no more PECL releases will
be done. In this case, a notice should be added to tell the users to
do not update or use the pecl package anymore (if they use a younger
php version than the one where the extension was bundled).
I hear what you're saying, I'm just reluctant to go with it because I'm
hopeful this won't be happening for much longer.
There's no reason
there couldn't be a PECL release of a symlinked core package, either (in
fact pecl/hash should probably have one following Solar Designer's
patch).
Or do you mean non-symlinked packages? If so, are there any PECL
packages
currently in core that are in this situation?It is not about how the CVS works or if it is used at all but if there
will have PECL releases or not once the extension is bundled. For the
record, what we have (or plan to) now is:
- symlink, common case, what we historically did and do
A lot of people don't like symlinking and want to move away from it, so
while it's the common case now - again, it probably won't be for much
longer.
- duplicated, how zip works, php-src/ext/zip is a module and is
unrelated to pecl/zip, one has to commit to both tree
Ouf, that's a bit of a burden...
- merge at release time, how phar may work as far as I remember
(that's actually my favourite one as it allows one to work only in
pecl and does not care too much about php releases in his development)
Yes - I believe this was Wez' original intention too.
- a PECL package is now in core and will still be maintained in PECL.
Core and PECL has two completely different roadmaps, I have no idea
how to actually solve this case :)Isn't that what CVS branches are for?
Yes, and how do you define which branch maps to which version? (See my
very first reply for a solution, we can do that later :)
I looked it up:
<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. At present
it's mostly the symlinked extensions that use those branches, but
pecl/intl's been using PHP_5_2 throughout with no apparent ill effect.
pecl4win and snaps currently don't appear to use PECL branches at all, but
that's probably because most PECL devs don't (yet)... there's no reason I
can see that both couldn't be made to have a handful of named CVS branches
override PECL HEAD for the appropriate PHP branch.
Given that development work generally should be done in CVS HEAD, and that
most packages are coded to run under all current versions of PHP, the only
way it makes sense to form any other kind of branch is if:
- your package is developed solely in CVS HEAD
- it builds against all target branches of PHP
- you want to do some private experimenting
In such a case the experimental code shouldn't really be made available as a
snapshot anyway - snapshots are intended for users, not for developers.
The real problem we have is that there's no obvious way to tell if a PECL
package release is geared to a specific branch - and that's only really a
problem because we effectively have two development branches in PHP at
present, HEAD and 5_3. Even so, most PECL devs aim to have their code work
with both 5_2 and 5_3 (and some go much, much further, as you know.)
It can be solved later for the snapshots, for the release it is rather
easy to do :)
In package.xml, yes - but that information doesn't appear along with the
package release info on the site. Having it there would be useful.
The later makes more sense to me. I can imagine a 2.x version for HEAD
and still having 1.x for 5.x
But then we should have a PHP_6_0 branch to host the version-specific 2.x
package development... not a couple of hundred differently-named branches
for the same purpose :) Snaps should build PHP HEAD (only) against your 2.x
and the rest against your 1.x (presumably in PECL HEAD), and both
pecl.php.net and package.xml should have the target PHP version clearly
marked. If/when PHP 6 supercedes PHP 5 you can put your old HEAD code into
the 5_* branch, do a final release from there and ignore it ever after. And
once you're working in a branch - you might as well keep it that way and use
HEAD for experiments, since nothing's going to be released from there and
your target PHP versions are already covered.
Should I start adding these now, where it's very obvious? And should
there
be some note inside the ORPHANED file to say what the extension needs?Can you post a list in the wiki or to the list so we can validate it
first?
Sure thing. (Could take me a while tho'.)
- Steph
The real problem we have is that there's no obvious way to tell if a PECL
package release is geared to a specific branch - and that's only really a
problem because we effectively have two development branches in PHP at
present, HEAD and 5_3. Even so, most PECL devs aim to have their code work
with both 5_2 and 5_3 (and some go much, much further, as you know.)
We have an easy way to do it for released packages, using package.xml.
That's why the PHP version dependency exists.
Cheers,
We have an easy way to do it for released packages, using package.xml.
That's why the PHP version dependency exists.
Please read the rest of my post :)
- Steph
Cheers,
Hi,
Re,
"will be maintained only there" means that no more PECL releases will
be done. In this case, a notice should be added to tell the users to
do not update or use the pecl package anymore (if they use a younger
php version than the one where the extension was bundled).I hear what you're saying, I'm just reluctant to go with it because I'm
hopeful this won't be happening for much longer.There's no reason
there couldn't be a PECL release of a symlinked core package, either (in
fact pecl/hash should probably have one following Solar Designer's
patch).
Or do you mean non-symlinked packages? If so, are there any PECL
packages
currently in core that are in this situation?It is not about how the CVS works or if it is used at all but if there
will have PECL releases or not once the extension is bundled. For the
record, what we have (or plan to) now is:
- symlink, common case, what we historically did and do
A lot of people don't like symlinking and want to move away from it, so
while it's the common case now - again, it probably won't be for much
longer.
- duplicated, how zip works, php-src/ext/zip is a module and is
unrelated to pecl/zip, one has to commit to both treeOuf, that's a bit of a burden...
- merge at release time, how phar may work as far as I remember
(that's actually my favourite one as it allows one to work only in
pecl and does not care too much about php releases in his development)Yes - I believe this was Wez' original intention too.
- a PECL package is now in core and will still be maintained in PECL.
Core and PECL has two completely different roadmaps, I have no idea
how to actually solve this case :)Isn't that what CVS branches are for?
Yes, and how do you define which branch maps to which version? (See my
very first reply for a solution, we can do that later :)I looked it up:
<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?
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.
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).
Cheers,
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 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.
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.
That said, I'd agree with you completely if it weren't for the differences
in PHP 6. As things are, though, I'd imagine a lot of PECL developers could
find a use for a PHP_6_0 branch that ships with/is built alongside PHP 6,
and leave their otherwise working code in PECL CVS HEAD for the time being.
Extension-specific experimental branches aren't really relevant to this
discussion because we're focusing on distribution for now.
- Steph
Cheers,
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
Hi Pierre,
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.
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 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.
What do you mean, you don't know what I'm referring to? And why do you say
'Again..'? Do you assume I haven't understood something? It seems more
likely to me you haven't read before responding. Again.
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?
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.
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.
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.
- Steph
Cheersm
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):
- Provide DLL per active branche
- 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,
Hi Pierre,
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'm totally confused by your confusion :) All of those builds could
prioritise an appropriately-named branch. The only one that currently does
this is the PHP build (any), for core extensions only. There's no total
independence of PHP in PECL because everything's geared towards one or
another of the PHP branches anyway. On the other hand, there are a number of
PECL modules that manage very well to cover all the bases in a single
package that builds against all PHP branches.
Those multi-version modules share a problem with the symlinked ones -
nowhere to experiment - since CVS HEAD is effectively a release area in both
cases.
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.
I did. It uses different PHP branches, not different PECL branches - the
only exception is for core modules, which are built (from a hard-coded list)
as branch-specific PHP extensions rather than as PECL modules. That said,
PECL developers don't tend to use PECL branches anyway - the vast majority
develop purely in CVS HEAD, which isn't a big problem so long as the code
builds against all versions of PHP.
From the very begining you defined what you like to do right now
(after having made some clarifications):
- Provide DLL per active branche
Actually that would be 'per release branch'. I've no intention of providing
PECL release DLLs for development branches - what would be the point?
- add version info in these DLLs
You missed:
- add version info in the PHP_MINFO section using the same macro.
The 2nd point is why you have created the RFC.
and 3rd...
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.
I don't do this in isolation, Pierre :)
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 certainly wasted a great deal of time yesterday responding to lengthy
emails rather than getting the job done. I don't intend to do the same
today.
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.
It's simple. I want to see PECL modules versioned in a standard way. The
issues raised concerning this (not all of them on-list) have been:
- symlinked modules: We agreed to use the -core tag for these for now.
- PHP-version-specific modules: (most likely case: a PECL module in CVS HEAD
builds against everything but PHP 6). This is dealt with in package.xml, but
we still don't have a way to distinguish a PHP 6-only module either through
phpinfo()or on the pecl.php.net download page. However, unless it's a core
module, that same code will be used in snaps. That was the bit I was trying
to talk about earlier, but the scripts for snaps and bundles (any) would
need to be adapted to prioritise the appropriate branch in PECL for my
suggestion to work. - versioning rules: You want to use PEAR's versioning structure, and I agree
with all of that apart from the -devel and -stable tags... x.0.0 is by
definition stable, anything less is by definition pre-alpha unless it has
an -alpha tag. However the existing PECL packages don't always use PEAR
rules, so we need to adapt a little to the current circumstances while also
recommending the PEAR x.x.x structure for new packages. Also, as with PHP,
anything other than a release should be tagged -dev, excepting modules that
ship with the core (as per temporary measure above). - space for experimental development: This isn't a major problem because a)
experimental code shouldn't really be distributed and b) it's already
possible to create a non-release branch or branches in PECL for this kind of
thing. Just look at SDO :)
We need to revisit: core module versioning and PHP-version-specific PECL
builds. I think we've already enough to work with for the majority of cases
tho'.
- Steph
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.It's simple. I want to see PECL modules versioned in a standard way. The
issues raised concerning this (not all of them on-list) have been:
Yes, and we have almost everything required to finalize the RFC. It
will obviously needs a transition period for all packages to get used
to these new versioning rules.
About the build themselves (and only the builds, versionning problem
is solved, almost), I really need to know what you are going to do. I
know that you will provide DLLs but I don't really know how, where and
from which sources. Am I right that all you want to do now is to
provide DLLs for PECL releases for each released PHP version? Or do
you want to do more than that right now?
Cheers,
Hi Pierre,
About the build themselves (and only the builds, versionning problem
is solved, almost), I really need to know what you are going to do. I
know that you will provide DLLs but I don't really know how, where and
from which sources. Am I right that all you want to do now is to
provide DLLs for PECL releases for each released PHP version? Or do
you want to do more than that right now?
Versioning first. Worry about the next bit later, or I won't have time to do
any of it!
I'll put up another RFC before I make any moves other than those already
discussed. Since I know how now an' all.
- Steph
Cheers,
Hi Pierre,
About the build themselves (and only the builds, versionning problem
is solved, almost), I really need to know what you are going to do. I
know that you will provide DLLs but I don't really know how, where and
from which sources. Am I right that all you want to do now is to
provide DLLs for PECL releases for each released PHP version? Or do
you want to do more than that right now?Versioning first. Worry about the next bit later, or I won't have time to do
any of it!
ok, as I said I will update the RFC later today. Good to have it finally :)
I'll put up another RFC before I make any moves other than those already
discussed. Since I know how now an' all.
For anything related to builds (outside your immediate needs for
manual builds of PECL releases for each PHP release), please hang your
horses. I have began to write one for the summer of code and it covers
almost everything you need as far as I can say. Thanks for your
understanding,
--
Pierre
http://blog.thepimp.net | http://www.libgd.org
Hi Pierre,
I'll put up another RFC before I make any moves other than those already
discussed. Since I know how now an' all.For anything related to builds (outside your immediate needs for
manual builds of PECL releases for each PHP release), please hang your
horses. I have began to write one for the summer of code and it covers
almost everything you need as far as I can say. Thanks for your
understanding,
Write one what? An RFC?
Don't worry, I'm a way off that yet anyway :)
- Steph
--
Pierre
http://blog.thepimp.net | http://www.libgd.org
Steph Fox wrote:
What a horrible name :) How about pecl_graveyard?
siberia
Steph Fox wrote:
I discovered tonight that I have full PECL karma, so the secondary
question is: does anyone have any objection to my making all (or most...
I'd leave the package.xml ones for now) PECL modules fit this versioning
model?
i'm fine with it, and i already changed pecl-gen / CodeGen_PECL
to create compliant code. I didn't roll a new release yet though
waiting for the final outcome of this ...
--
Hartmut Holzgraefe, Principal Support Engineer
.
Discover new MySQL Monitoring & Advisory features at:
http://www.mysql.com/products/enterprise/whats_new.html
Hauptsitz: MySQL GmbH, Dachauer Str.37, 80335 München
Geschäftsführer: Kaj Arnö - HRB München 162140
Steph Fox wrote:
I discovered tonight that I have full PECL karma, so the secondary
question is: does anyone have any objection to my making all (or most...
I'd leave the package.xml ones for now) PECL modules fit this versioning
model?i'm fine with it, and i already changed pecl-gen / CodeGen_PECL
to create compliant code. I didn't roll a new release yet though
waiting for the final outcome of this ...
I think you can go ahead with the #define PHP_[...]_VERSION part, we
all agree on that already ( I will update the wiki later today). Not
sure if the rest affects codegen, do you check the version format
itself or do you realy on the pear installer for this task?
Cheers,
Pierre Joye wrote:
Not
sure if the rest affects codegen, do you check the version format
itself or do you realy on the pear installer for this task?
it is not checked yet, but it is an open TODO item anyway ...
--
Hartmut Holzgraefe, Principal Support Engineer
.
Discover new MySQL Monitoring & Advisory features at:
http://www.mysql.com/products/enterprise/whats_new.html
Hauptsitz: MySQL GmbH, Dachauer Str.37, 80335 München
Geschäftsführer: Kaj Arnö - HRB München 162140
Hi Hartmut,
I discovered tonight that I have full PECL karma, so the secondary
question is: does anyone have any objection to my making all (or most...
I'd leave the package.xml ones for now) PECL modules fit this versioning
model?
i'm fine with it, and i already changed pecl-gen / CodeGen_PECL
to create compliant code. I didn't roll a new release yet though
waiting for the final outcome of this ...
Cool :) thanks!
- Steph
--
Hartmut Holzgraefe, Principal Support Engineer
.
Discover new MySQL Monitoring & Advisory features at:
http://www.mysql.com/products/enterprise/whats_new.html
Hauptsitz: MySQL GmbH, Dachauer Str.37, 80335 München
Geschäftsführer: Kaj Arnö - HRB München 162140