On Tue, Jan 31, 2012 at 6:51 PM, Christoph Leiter <[email protected]> wrote: >> AFAIK the proper way of deprecating would be to deprecate in 6.0 and >> remove in 7.0, if we are going to utilize semver. > > > I think it's okay to deprecate it in 1.5.x and remove it in 6.0: > > | When you deprecate part of your public API, you should do two things: > | (1) update your documentation to let users know about the change, (2) > | issue a new minor release with the deprecation in place. Before you > | completely remove the functionality in a new major release there > | should be at least one minor release that contains the deprecation so > | that users can smoothly transition to the new API.
I can quote scripture as well :-) > 8. Minor version Y (x.Y.z | x > 0) MUST be incremented if new, > backwards compatible functionality is introduced to the public > API. It MUST be incremented if any public API functionality is > marked as deprecated. It MAY be incremented if substantial > new functionality or improvements are introduced within the > private code. It MAY include patch level changes. Patch version > MUST be reset to 0 when minor version is incremented. So according to this (and rule #3) a 1.6.0 MUST be released with the deprecation in place. But as I already stated, 1.5 does not use semver, so there is no reason to be anal about it. Martijn
