Re: Re: About that PECL versioning thing

On Mon, Mar 24, 2008 at 6:05 PM, Steph Fox <steph@zend.com> 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, -- Pierre http://blog.thepimp.net | http://www.libgd.org