Hi Steph,
On Mon, Mar 24, 2008 at 3:08 PM, Steph Fox <[EMAIL PROTECTED]> 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, -- 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
