Re: cvs: pear /PEAR_PackageFileManager ChangeLog NEWS

Laurent Laville wrote: > Gregory Beaver a écrit : >> Laurent Laville wrote: >> >>> Gregory Beaver a écrit : >>> >>>> Laurent Laville wrote: >>>> >>>>> farell Fri Oct 6 12:20:31 2006 UTC >>>>> >>>>> Modified files: /pear/PEAR_PackageFileManager >>>>> ChangeLog NEWS Log: >>>>> update changelogs related to new feature : import all previous >>>>> tasks files easily >>>>> + - exportCompatiblePackageFile1() method is maked as >>>>> deprecated, >>>>> + because package xml 1.0 will not be supported with stable >>>>> version 1.6.0 >>>>> >>>> Hi Laurent, >>>> >>>> I'm afraid this is not OK - dropping package.xml 1.0 export is a huge >>>> change to the API and not really necessary. >>> I don't see why its a huge change . >>> Drop export compatible package xml 1.0 require only to remove the >>> PEAR_PackageFileManager2::exportCompatiblePackageFile1() method. >>> >>> If maintainers still want to produce a package.xml 1.0, there are still >>> PEAR_PackageFileManager 1.5.x, as i've noticed lot of them use again. >>> >> >> This is not an option. You can't install both 1.5.x and 1.6.x as you >> know, and we should never actively encourage developers not to upgrade. >> >> > Of course we can't install both versions , but as you know, and as i > wanted to explain : > With 1.6.x we have both classes (PFM and PFM2) to generate package > xml 1.0 and package xml 2.0 > > If PFM2 seems to be the PEAR packager future , i don't see any good > reason, to be against option to remove the exportcompatible function > that do almost the same thing as PFM class itself. > User who still want to generate package 1.0 will continue to use PFM > while user who want begin to generate package 2.0 > will do it with PFM2, and this with only one version (1.6.0). Hi Laurent, The good reason, and the only reason is that once we released 1.6.0b1, state beta, the API was frozen. You will be breaking scripts to remove this now. The only good reason to remove a feature is if it causes errors, critical bugs, or something else. What I hear from you is that you think the feature is inconvenient, but this is illogical - it doesn't require maintenance, and is lightweight. Your argument of it not exporting a compatible package.xml is not true - compatible does not mean identical. Look at PEAR's package.xml files. package-PEAR.xml and package2.xml have vastly differing dependencies, but both successfully install the PEAR package. I don't think we should release an RC until the documentation for PFM2 is in place at pear.php.net in docbook, otherwise it's hard to verify that it behaves as documented for the first stable release. Thanks, Greg