commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Heger <oliver.he...@oliver-heger.de>
Subject Re: [configuration] Plan for 2.0
Date Sun, 09 Sep 2012 17:11:26 GMT
Am 09.09.2012 18:28, schrieb Benedikt Ritter:
> Hi Oliver,
>
> there are a lot of @author tags. As far as I know, the use of author
> tags is deprecated in commons, so the mentioned developers and
> contributors should be moved to pom.xml and changes.xml.

Yes, this is true. When changing code, e.g. when we switched to Java 1.5 
(which affected most source files), I used to remove my own @author 
tags. However, I am reluctant to remove the @author tags of other's. 
IIRC, there has not yet been a consensus how to deal with existing tags. 
Especially, there were committers active in [configuration] who voted 
against removing these tags.

Oliver

>
> Benedikt
>
> 2012/9/7 Oliver Heger <oliver.heger@oliver-heger.de>:
>> Hi all,
>>
>> the pom was updated to make 2.0-SNAPSHOT the current development version.
>> This means we are free to implement major changes without having to enforce
>> binary backwards compatibility.
>>
>> The question is: What are the goals for version 2.0? I would recommend to
>> define a clear focus so that the next release will not take too long.
>> Obviously there are already people waiting for a [configuration] version
>> compatible with [lang3].
>>
>> Some points I have in mind are the following ones:
>> - Switch to [lang3]. This is the main reason for going to version 2.0
>> because this cannot be done in a binary compatible way.
>> - Improve thread safety and concurrent implementations in general.
>> - Rework reloading. This is related to the previous point because I think
>> the tight coupling of the current reloading implementation is one of the
>> root causes making the implementation of thread-safe configurations so hard.
>> - Have a look at older Jira tickets which have been postponed because they
>> would break binary compatibility.
>>
>> Any other points, wishes, or opinions? We should discuss the points
>> separately when it comes to their implementation.
>>
>> Oliver
>>
>> ---------------------------------------------------------------------
>> 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


Mime
View raw message