Re: Re: deprecating

Any change should be interpreted as "do not remove public methods", adding new methods is not a BC break nor is adding new parameters which have a default value. Arnaud. Joe Stump wrote:

Supposedly you can, but according to the RFC any change in the API would require I roll out some other package (ie. Foo_Bar2). The problem with this package is that 0.2 was released stable (evidently before this RFC was accepted) and then magically jumped to 1.0.1beta. Also, since when is deprecating something breaking backwards compatibility? It would still function as it did before. And, if I deprecate something going from 1.0 to 2.0 (but leave it there, while changing all docs) why can't I remove it in 3.0? People would have had an entire major point release to prepare for the change. Also, if my API doesn't change do I still have to move everything into a new package? Multiple new packages makes pretty much zero sense - after all this is exactly what version numbering is for. You should know that 1.0 and 2.0 have different feature sets without having to install 14 different versions of the same package. A better approach, IMO, would be to have package.xml enable developers to somehow warn a person about potential problems *before* pear installed the new package. For instance, pear would notice that I'm going from 1.0 to 2.0 and stop to tell the person upgrading that upgrading will cause X, Y and Z to break and to update their code, if needed, before installing. --Joe