# About that PECL versioning thing
- Thread: https://externals.io/message/36360
- Original archive: https://news-web.php.net/php.internals/36360
- Started by Steph Fox on 2008-03-23T02:51:14+00:00
- Messages: 34
- Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL)
- Next page: https://externals.io/message/36360.md?page=2
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt
---
## #36360 — Steph Fox — 2008-03-23T02:51:14+00:00
URL: https://externals.io/message/36360#36360
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
---
## #36368 — Hannes Magnusson — 2008-03-23T12:01:09+00:00
URL: https://externals.io/message/36360#36368 · In reply to: #36360
> 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
---
## #36369 — johannes@php.net — 2008-03-23T12:39:29+00:00
URL: https://externals.io/message/36360#36369 · In reply to: #36368
Hi,
>
> > […]
>
> 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
---
## #36374 — Steph Fox — 2008-03-23T13:34:36+00:00
URL: https://externals.io/message/36360#36374 · In reply to: #36369
Hi,
> > […]
That's the basic idea, yes.
> > […]
>
> 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
---
## #36379 — Hannes Magnusson — 2008-03-23T14:07:38+00:00
URL: https://externals.io/message/36360#36379 · In reply to: #36374
> Hi,
>
>
> > […]
>
> That's the basic idea, yes.
>
>
> > […]
>
> 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
---
## #36383 — Steph Fox — 2008-03-23T14:35:09+00:00
URL: https://externals.io/message/36360#36383 · In reply to: #36379
> 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
---
## #36406 — Steph Fox — 2008-03-23T19:47:40+00:00
URL: https://externals.io/message/36360#36406 · In reply to: #36369
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
---
## #36419 — Pierre Joye — 2008-03-24T11:25:56+00:00
URL: https://externals.io/message/36360#36419 · In reply to: #36360
> 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,
--
Pierre
http://blog.thepimp.net | http://www.libgd.org
---
## #36428 — Steph Fox — 2008-03-24T14:08:41+00:00
URL: https://externals.io/message/36360#36428 · In reply to: #36419
Hello Pierre,
> > […]
>
> 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?
> > […]
>
> 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,
> --
> Pierre
> http://blog.thepimp.net | http://www.libgd.org
---
## #36430 — Gregory Beaver — 2008-03-24T14:22:26+00:00
URL: https://externals.io/message/36360#36430 · In reply to: #36428
Steph Fox wrote:
> Hello Pierre,
>
> > […]
>
> 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
---
## #36436 — Pierre Joye — 2008-03-24T16:14:45+00:00
URL: https://externals.io/message/36360#36436 · In reply to: #36428
Hi Steph,
> Hello Pierre,
>
>
> > […]
>
> 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.
> > […]
>
> 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 :)
> > […]
>
> 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.
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.
> > […]
>
> 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.
> > […]
>
> 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.
> > […]
>
> 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,
--
Pierre
http://blog.thepimp.net | http://www.libgd.org
---
## #36438 — Steph Fox — 2008-03-24T17:05:11+00:00
URL: https://externals.io/message/36360#36438 · In reply to: #36436
Hi Pierre...
> > […]
>
> 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 :)
> > […]
>
> 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.
> > […]
>
> Everything being in php-src is core. No matter what we'll do next
> month or in 10 years.
>
> > […]
>
> 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.
>
> > […]
>
> 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...
> > […]
>
> 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 :)
> > […]
>
> 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!
> > […]
>
> 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,
> --
> Pierre
> http://blog.thepimp.net | http://www.libgd.org
---
## #36442 — Pierre Joye — 2008-03-24T17:25:34+00:00
URL: https://externals.io/message/36360#36442 · In reply to: #36438
> > […]
>
> 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' 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.
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:
1. a PECL package is now in core and will be maintained only there.
The PECL homepage has to say it
2. 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
3. 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).
> > […]
>
> No. We have new PHP versions every now and again...
I obviously meant to do not build it again for a given PHP version.
> > […]
>
> 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.
> > […]
>
> 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.
> > […]
>
> 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.
> > […]
>
> 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,
--
Pierre
http://blog.thepimp.net | http://www.libgd.org
---
## #36446 — Steph Fox — 2008-03-24T18:05:45+00:00
URL: https://externals.io/message/36360#36446 · In reply to: #36442
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...
> > […]
>
> 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:
>
> 1. 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?
> 2. 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!
> 3. 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?
> > […]
>
> 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.
> > […]
>
> 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
> > […]
>
> 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!
> > […]
>
> 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.
> > […]
>
> 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.
> > […]
>
> 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.
>
> > […]
>
> 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,
> --
> Pierre
> http://blog.thepimp.net | http://www.libgd.org
---
## #36444 — Pierre Joye — 2008-03-24T18:23:01+00:00
URL: https://externals.io/message/36360#36444 · In reply to: #36446
re,
> > […]
>
> Yes, that's the plan. But, one thing at a time...
The "versionning" RFC is the perfect place to describe ... versions :)
> > […]
>
> 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.
"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)
> > […]
>
> This 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 :)
> > […]
>
> 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 :)
> > […]
>
> 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 :)
> > […]
>
> 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
> > […]
>
> 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,
--
Pierre
http://blog.thepimp.net | http://www.libgd.org
---
## #36449 — Gregory Beaver — 2008-03-24T19:22:28+00:00
URL: https://externals.io/message/36360#36449 · In reply to: #36446
Steph Fox wrote:
> What a horrible name :) How about pecl_graveyard?
siberia
---
## #36451 — Christopher Jones — 2008-03-24T20:11:17+00:00
URL: https://externals.io/message/36360#36451 · In reply to: #36368
Hannes Magnusson wrote:
>
> > […]
>
> 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
---
## #36457 — Steph Fox — 2008-03-24T21:00:59+00:00
URL: https://externals.io/message/36360#36457 · In reply to: #36444
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.
> > […]
>
> 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.
> > […]
>
> 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:
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.
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:
1. your package is developed solely in CVS HEAD
2. it builds against all target branches of PHP
3. 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.
> > […]
>
> 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
---
## #36458 — Pierre Joye — 2008-03-24T21:09:47+00:00
URL: https://externals.io/message/36360#36458 · In reply to: #36457
> 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,
--
Pierre
http://blog.thepimp.net | http://www.libgd.org
---
## #36459 — Steph Fox — 2008-03-24T21:12:42+00:00
URL: https://externals.io/message/36360#36459 · In reply to: #36458
> 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,
> --
> Pierre
> http://blog.thepimp.net | http://www.libgd.org
---
## #36460 — Pierre Joye — 2008-03-24T21:49:42+00:00
URL: https://externals.io/message/36360#36460 · In reply to: #36457
Hi,
> Re,
>
>
> > […]
>
> 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.
>
>
> > […]
>
> 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.
>
>
> > […]
>
> Ouf, that's a bit of a burden...
>
>
> > […]
>
> Yes - I believe this was Wez' original intention too.
>
>
> > […]
>
> I looked it up:
>
>
> 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.
>
>
> 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,
--
Pierre
http://blog.thepimp.net | http://www.libgd.org
---
## #36462 — Steph Fox — 2008-03-24T22:10:49+00:00
URL: https://externals.io/message/36360#36462 · In reply to: #36460
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 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,
> --
> Pierre
> http://blog.thepimp.net | http://www.libgd.org
---
## #36468 — Pierre Joye — 2008-03-25T00:07:26+00:00
URL: https://externals.io/message/36360#36468 · In reply to: #36462
> Hi Pierre,
>
>
> > […]
>
> 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 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.
> > […]
>
> 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
---
## #36472 — Steph Fox — 2008-03-25T01:13:40+00:00
URL: https://externals.io/message/36360#36472 · In reply to: #36468
Hi Pierre,
> > […]
>
> 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'?
> > […]
>
> 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.
> > […]
>
> 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
> --
> Pierre
> http://blog.thepimp.net | http://www.libgd.org
---
## #36477 — Hartmut Holzgraefe — 2008-03-25T09:44:44+00:00
URL: https://externals.io/message/36360#36477 · In reply to: #36360
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
---
Next page: https://externals.io/message/36360.md?page=2