Re: [RFC_v3] Handling Backwards Compatibility in PEAR [hopefully the final draft]

Hi Greg, Here are my opinions: Wednesday, September 24, 2003, 7:36:37 PM, Greg Beaver wrote: > The Solution: > ------------ > The API of a PEAR package may only break BC if: > 1) The packages is in the preparation phase to a new major version number > 2) A new major stable release is made I see no difference between these two points. I guess you can merge them safely. No BC is allowed if no major version is bumped. The 1) invites to think that in 1.9beta they can break the api. > It is up to the lead developers to determine whether BC needs to be > broken. It is highly encouraged to carefully select the API before > version 1.0 so that changes to the API that break BC will not be > necessary. This paragraph should be stronger IMHO. "BC breaks are strongly discourage in PEAR" or something so. Also some tips may help people to prevent that to happen. We could discuss those in other 100 posts thread ;). > The postfix format shall be > _vX > where X is the major version number. The PEAR directory naming > conventions shall remain the same, but files in newer versions will > follow this format: > Foo.vX.php contains class Foo_vX > Foo/vX/support.php contains class Foo_vX_support I really preffered just FooX, but it's okay reading the emails. Btw there is a typo in _vX, Foo.vX.php should be Foo_vX.php. > Announcing API changes: > ----------------------- > If there is a need to remove a public or protected method, then > 1) If it is possible to implement the same functionality in other > methods then such functionality should be added and the method should be > marked deprecated in major release. This means that the method can be > removed in any of the following major releases. > 2) If it is not possible to implement the same functionality or if the > method is removed due to API simplification then the package should > enter beta stage before the next major release. > Reasoning: API breaks will not happen without due warning. If you do not > use deprecated methods and the next major version comes out, you can > safely upgrade to it. If the package you depend upon enters alpha/beta > stage, then you should test for compatibility before upgrading. And the place for the announce? :-) For the rest I think is quiet good. -- Tomas V.V.Cox mailto:cox@idecnet.com