Re: cvs: pear /PEAR_PackageFileManager ChangeLog NEWS

Gregory Beaver a écrit :

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. Greg, I though you don't understand my point of view: i'll try to explain better with an example. If you have a look on sample "updatepackage.php" into PEAR repository [1], you'll certainly notice that the script is lightweight. No more needed to have all tasks files replacement, end-of-line, ... because we could use with beta 5 the "clearcontents" option. If i decided to code an extra exportCompatiblePackageFile1() method, i won't get these sames tasks files replacement, until : 1. we choose to fix it : but last time you told me you are against. Read again your answer (sent to me on Sep, 3) to my mail from August 31 (both are sent offline, not on mailing list) 2. programmer decide to code himself after a exportCompatiblePackageFile1() all task replacement once again (time lost) 3. finally, as most of user, decide to code only once generator script with all options (task files, add maintainer , dependencies ...) as it was each time the first usage-day. ==> In such condition, and only in this case, of course exportCompatiblePackageFile1() have sense. But also in this same case, i don't see usage of importOptions().

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.

As i'm certainly right about my post on pear general mailing list named "is there problem with smtp server ?", while i did not yet receive any answer. I confirm i sent to you an offline mail to your php.account (cellog@php.net) on Oct 14, and dont get yet an answer from you. Here is a copy : ------ Greg, I'm under writing a full user guide with tutorial about PEAR_PackageFileManager. I need your agreement to include part of PEAR docs writes you've done in past and included into the PEAR Manual. I think i could open on my website a draft of this manual wrote with DocBook and under the Creative Common License 2.0 ( http://creativecommons.org/licenses/by/2.0/ ) when i'll release the beta 5 Thursday 19 Oct ( 2 months day-to-day after beta 4) . But this doc will not be official until RC1 (no date yet planned). Laurent ------

Thanks, Greg

[1] http://cvs.php.net/viewvc.cgi/pear/PEAR_PackageFileManager/examples/