> ie) Unwanted code is deprecated for the next major or minor release, and > removed in the major release following that. > > so: > > 1.0 -> 2.0, Foo.foo is deprecated > 2.0 -> 2.1, Foo.bar is deprecated > 2.1 -> 3.0, Foo.foo and Foo.bar are both removed > > or if it is such that we just need to do N releases between deprecation > and removal, specify that. Basically get something simple and effective > standardised to stop future debates.
I'd suggest: patch number 1.2.1 -> 1.2.2 = bugfix, no API or behavioural changes minor number 1.2.3 -> 1.3.0 = adding functionality/API, still backwards compatible (classes or methods may be added) major number 2.0.0 -> = risk for backward incompatibilities With this scheme, the removal of deprecated methods and classes needs a new major release number. /O -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
