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

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?

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