Electronics & Programming

develissimo

Open Source electronics development and programming

  • You are not logged in.
  • Root
  • » PHP
  • » [PHP-DEV] Re: [PECL-DEV] About that PECL versioning thing [RSS Feed]

#1 March 23, 2008 15:36:20

Steph F.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] Re: [PECL-DEV] About that PECL versioning thing


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 problemfor 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 alreadyhas one? then we can see how much of an issue it is or isn't.- Steph-Hannes

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:http://www.php.net/unsub.php--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:http://www.php.net/unsub.php

Offline

#2 March 24, 2008 15:08:34

Steph F.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] Re: [PECL-DEV] About that PECL versioning thing


Hello Pierre,Aside from Pierre's arguments in favour of using package.xml to set theextension version (which 3 PECL extensions - two of them Pierre's - doatpresent), does anyone have any objection to the proposal athttp://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! Iactually want to extend package.xml to give more information (QA related) sothat people have more of a clue about what they're dealing with. E.g. codecoverage %, maintenance status, whether the package is of general/specialinterest (this last mostly for hosting companies) and some kind of gradingsystem. But this is all open to discussion and probably won't happen for along 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 wasgoing 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 maymean 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'snot. This isn't going to happen overnight, so I've compromised by not usingthe -dev tag for symlinked extensions and by applying the RC data to PECLbuilds only. There are a few other packages that won't get a -dev tagbecause they haven't been touched since the last (often first) packagerelease, ie they're not under active development. These aren't necessarilystable, but that's a whole separate issue... we need a way to clearly markorphaned 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 countmy asking permission from various individuals to add versioning to theirpackages?I discovered tonight that I have full PECL karma, so the secondaryquestionis: does anyone have any objection to my making all (or most... I'dleavethe 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 Ihave checked out locally. It's a relative non-issue, for the reasons givenabove.I started work yesterday on extensions where the maintainer has givenexplicit permission or where I know for sure they're no longer involved inPHP development (Sterling, Tal). Amazingly, fribidi still works after fiveyears of zero interference :)I'll post patches for the rest on a per-maintainer basis over the comingweeks, but I have to say there are a number of PECL packages I believe arelong-time orphans.- StephCheers,
--
Pierrehttp://blog.thepimp.net|http://www.libgd.org--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:http://www.php.net/unsub.php--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:http://www.php.net/unsub.php

Offline

#3 March 24, 2008 15:22:52

Gregory B.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] Re: [PECL-DEV] About that PECL versioning thing


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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:http://www.php.net/unsub.php

Offline

#4 March 24, 2008 17:17:26

Pierre J.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] Re: [PECL-DEV] About that PECL versioning thing


Hi Steph,


On Mon, Mar 24, 2008 at 3:08 PM, 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!

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


> > 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,
--
Pierrehttp://blog.thepimp.net|http://www.libgd.org--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:http://www.php.net/unsub.php

Offline

#5 March 24, 2008 18:05:10

Steph F.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] Re: [PECL-DEV] About that PECL versioning thing


Hi Pierre...interest (this last mostly for hosting companies) and some kind ofgradingsystem. But this is all open to discussion and probably won't happen foralong 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 inthat 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 if version_compare() can deal withit,it's in - I don't see how any other approach can be justified, since itmaymean 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 thatit doesn't recognize 1.0.0 and 1.0 as the same value, but that's only aproblem if you change existing patterns. (Bear in mind that there areexisting patterns for everything that ever had a PECL release, which shouldbe honoured if the 'pecl' command is to keep working.) Also, I've foundnothing in PECL that deems itself 'stable' at 0.1.0, so I think that's a bitof a red herring. People seem to have been very good about that on thewhole.> 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) andwhat'snot.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 usingthe -dev tag for symlinked extensions and by applying the RC data toPECLbuilds 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 inMINFO and RC stuff only - package.xml obviously won't use it, and PECLpackage 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 bothcases the PHP version information is also available. A $Revision or $Idstring in MINFO would also be useful in core extensions, purely from thebug-tracking PoV.This way you can easily see 1) the package release version, 2) whether ornot it ships with PHP (and which version), and 3) when the code was lastupdated. We also avoid Johannes' problem of needing PECL release packages ina 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 necessarilystable, but that's a whole separate issue... we need a way to clearlymarkorphaned 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 whichIhave checked out locally. It's a relative non-issue, for the reasonsgivenabove.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 comingweeks, but I have to say there are a number of PECL packages I believearelong-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 wayof 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 peclanymore)- 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 maydisagree with me.) Also, who gets to make that decision?- StephCheers,
--
Pierrehttp://blog.thepimp.net|http://www.libgd.org--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:http://www.php.net/unsub.php--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:http://www.php.net/unsub.php

Offline

#6 March 24, 2008 18:05:10

Steph F.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] Re: [PECL-DEV] About that PECL versioning thing


Hi Pierre...interest (this last mostly for hosting companies) and some kind ofgradingsystem. But this is all open to discussion and probably won't happen foralong 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 inthat 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 if version_compare() can deal withit,it's in - I don't see how any other approach can be justified, since itmaymean 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 thatit doesn't recognize 1.0.0 and 1.0 as the same value, but that's only aproblem if you change existing patterns. (Bear in mind that there areexisting patterns for everything that ever had a PECL release, which shouldbe honoured if the 'pecl' command is to keep working.) Also, I've foundnothing in PECL that deems itself 'stable' at 0.1.0, so I think that's a bitof a red herring. People seem to have been very good about that on thewhole.> 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) andwhat'snot.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 usingthe -dev tag for symlinked extensions and by applying the RC data toPECLbuilds 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 inMINFO and RC stuff only - package.xml obviously won't use it, and PECLpackage 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 bothcases the PHP version information is also available. A $Revision or $Idstring in MINFO would also be useful in core extensions, purely from thebug-tracking PoV.This way you can easily see 1) the package release version, 2) whether ornot it ships with PHP (and which version), and 3) when the code was lastupdated. We also avoid Johannes' problem of needing PECL release packages ina 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 necessarilystable, but that's a whole separate issue... we need a way to clearlymarkorphaned 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 whichIhave checked out locally. It's a relative non-issue, for the reasonsgivenabove.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 comingweeks, but I have to say there are a number of PECL packages I believearelong-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 wayof 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 peclanymore)- 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 maydisagree with me.) Also, who gets to make that decision?- StephCheers,
--
Pierrehttp://blog.thepimp.net|http://www.libgd.org--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:http://www.php.net/unsub.php--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:http://www.php.net/unsub.php

Offline

#7 March 24, 2008 18:26:26

Pierre J.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] Re: [PECL-DEV] About that PECL versioning thing


On Mon, Mar 24, 2008 at 6:05 PM, Steph Fox <> wrote:

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


> > 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,
--
Pierrehttp://blog.thepimp.net|http://www.libgd.org--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:http://www.php.net/unsub.php

Offline

#8 March 24, 2008 19:23:51

Pierre J.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] Re: [PECL-DEV] About that PECL versioning thing


re,

On Mon, Mar 24, 2008 at 7:05 PM, Steph Fox <> wrote:

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

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

> > 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!

That's scenarii, not something I like to enforce, only an enumaration
of existing cases :)

> > 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?

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.dllIt 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,
--
Pierrehttp://blog.thepimp.net|http://www.libgd.org--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:http://www.php.net/unsub.php

Offline

#9 March 24, 2008 19:29:12

Steph F.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] Re: [PECL-DEV] About that PECL versioning thing


Oooh....What a horrible name :) How about pecl_graveyard?or siberia? :)

- Steph

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:http://www.php.net/unsub.php

Offline

#10 March 24, 2008 19:39:32

Steph F.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] Re: [PECL-DEV] About that PECL versioning thing


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 useinMINFO 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 inbothcases 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) whetherornot it ships with PHP (and which version), and 3) when the code was lastupdated. We also avoid Johannes' problem of needing PECL releasepackages ina 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:

1. 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 madein php-src ext/whatever are really going into PECL CVS. There's no reasonthere couldn't be a PECL release of a symlinked core package, either (infact pecl/hash should probably have one following Solar Designer's patch).Or do you mean non-symlinked packages? If so, are there any PECL packagescurrently 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 matchedThis would be the ideal scenario all round, but enforcing it may beproblematic!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?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 extensionsrc 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 toclearly>> 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, allaffected branches of the same extension will have the same version number -based on the most recent PECL release and tagged with -core. I'm onlylooking 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 betterwayof approaching this.)ORPHANED may do it as well.Should I start adding these now, where it's very obvious? And should therebe some note inside the ORPHANED file to say what the extension needs? To goback to fribidi again (because it's a simple extension that hasn't beentouched in 4 years and I know Tal's not likely to come back to it), there'sa single compiler warning due to snprintf() changes in PHP and no tests atall. 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 thedifference.How do we know if an extension is 'dead', what are the criteria forthat?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?

- StephCheers,
--
Pierrehttp://blog.thepimp.net|http://www.libgd.org--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:http://www.php.net/unsub.php--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:http://www.php.net/unsub.php

Offline

  • Root
  • » PHP
  • » [PHP-DEV] Re: [PECL-DEV] About that PECL versioning thing [RSS Feed]

Board footer

Moderator control

Enjoy the 16th of December
PoweredBy

The Forums are managed by develissimo stuff members, if you find any issues or misplaced content please help us to fix it. Thank you! Tell us via Contact Options
Leave a Message
Welcome to Develissimo Live Support