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

Tomas V.V.Cox 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.

I agree with this.

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

Good idea, I'll add this.

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. [snip]

And the place for the announce? :-) I don't know if this needs to be explicit, but I suppose there should be examples of good places to announce this :)

Greg