Re: cvs: pear /PEAR_PackageFileManager ChangeLog NEWS

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

Few of them have already migrated from 1.5.x to 1.6.x

This is because 1.5.x is stable, and 1.6.x is not. Not really a good reason because PFM class and file generator plugins are the same in package version 1.5.3 and 1.6.0b4

I used myself some package what are in beta status, and are also pretty stable as package in stable status.

We never talked about this idea.

And remember, when i told you about implementing full import on PEAR_PackageFileManager class. Same feature i've done now on import all tasks files from a package xml 2.0 with "clearcontents" set to false.

Right, but this has nothing to do with exporting a compatible package.xml 1.0. When i told to you about implementing ability to give a full import (task file: replaces, eol) both on PFM2 and PFM classes, remember what you said to me. (...)

In such condition, i don't see why we should keep the exportcompatible function what can't give the same features : import all => with "clearcontents" = false import all task files, eol, postinstallscript (with package 2.0) and nothing with package 1.0 It won't give a real compatible package 1.0

There is no good reason to remove this feature, please revert the change. The only good reason is if it prevents implementing a better way to generate a package.xml 1.0 from the version 2 PEAR_PFM2 object. I don't see that you have replaced this functionality, only removed it. Considering that the code to do this is about 20 lines of code, the change just doesn't make any sense to me - perhaps I've missed something big? Sorry, but here i don't understand what you mean. Please clarify !

Thanks, Greg Thanks in advance

Laurent