[POOL] changes for 2.0 - how much needs to be deprecated now?

[sebb <se...@gmail.com>]

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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: [POOL] changes for 2.0 - how much needs to be deprecated now?

[Phil Steitz <ph...@gmail.com>]

sebb wrote:
> On 23/04/2010, Gary Gregory <GG...@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.

I think it is reasonable to deprecate things that we know are not
going to remain in 2.0 and we can and should do that as soon as we
agree on each case.  I don't think we have to be comprehensive and I
don't think we need a separate release just to do the deprecations.

I think the important things to signal to users - and allow people
to complain about / suggest alternatives to - are things related to
mutability that we intend to remove, for example, the setFactory and
setLifo methods.
> 
> 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.

+1

Phil
> 
> http://commons.apache.org/releases/versioning.html
> 
>>  Gary Gregory
>>  Senior Software Engineer
>>  Seagull Software
>>  email: ggregory@seagullsoftware.com
>>  email: ggregory@apache.org
>>  www.seagullsoftware.com
>>
>>
>>
>>  > -----Original Message-----
>>  > From: sebb [mailto:sebbaz@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-unsubscribe@commons.apache.org
>>  > For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>>  ---------------------------------------------------------------------
>>  To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>  For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: [POOL] changes for 2.0 - how much needs to be deprecated now?

[sebb <se...@gmail.com>]

On 23/04/2010, Gary Gregory <GG...@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: ggregory@seagullsoftware.com
>  email: ggregory@apache.org
>  www.seagullsoftware.com
>
>
>
>  > -----Original Message-----
>  > From: sebb [mailto:sebbaz@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-unsubscribe@commons.apache.org
>  > For additional commands, e-mail: dev-help@commons.apache.org
>
>
>  ---------------------------------------------------------------------
>  To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>  For additional commands, e-mail: dev-help@commons.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

RE: [POOL] changes for 2.0 - how much needs to be deprecated now?

[Gary Gregory <GG...@seagullsoftware.com>]

We could have stages:
- Now: Mark all methods we want as deprecated, which gives us a record of intention at least.
- 2.0: Drop private and package private deprecated methods
- 2.1: Drop protected and public deprecated methods

Gary Gregory
Senior Software Engineer
Seagull Software
email: ggregory@seagullsoftware.com
email: ggregory@apache.org
www.seagullsoftware.com 


> -----Original Message-----
> From: sebb [mailto:sebbaz@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org