Please change the subject line when thread veers off the original topic like this one has.
On Thu, 9 Jan 2003, Ola Berg wrote: > > 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]>