On 23/04/2010, Gary Gregory <ggreg...@seagullsoftware.com> wrote: > We could have stages: > - Now: Mark all methods we want as deprecated, which gives us a record of > intention at least.
The problem is that it is probably going to be difficult to determine all the methods that could/should be dropped without actually doing the work for 2.0. We might then have to create a new minor release containing all the deprecations and probably nothing else. Which is why I asked whether it was necessary. > - 2.0: Drop private and package private deprecated methods > - 2.1: Drop protected and public deprecated methods We cannot drop public methods in a minor version change, even if the methods have been deprecated, as minor releases are supposed to be drop-in replacements. http://commons.apache.org/releases/versioning.html > Gary Gregory > Senior Software Engineer > Seagull Software > email: ggreg...@seagullsoftware.com > email: ggreg...@apache.org > www.seagullsoftware.com > > > > > -----Original Message----- > > From: sebb [mailto:seb...@gmail.com] > > Sent: Friday, April 23, 2010 12:42 > > To: Commons Developers List > > Subject: [POOL] changes for 2.0 - how much needs to be deprecated now? > > > > There are a lot of classes which have setters for private fields that > > are also set by the constructors. > > > > In most cases there is no need to change the values of the fields > > after construction, so the setters could be dropped and the fields > > made final thus improving thread-safety. > > Final fields also make testing easier - fewer states to check. > > > > (In some cases using the setter after the class has been in use for a > > while might well cause problems even if all access is thread-safe - > > e.g. changing LIFO behaviour midstream would not make sense.) > > > > Dropping the setter methods is an API change, so my question is: > > Do all such changes have to be flagged up by deprecating the setters > > in a previous release? > > Or can a major release just drop the methods? > > > > If deprecation is required, then we should probably start adding > > deprecated annotations now. > > I suspect there will be quite a lot. > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
