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 Sat, 08 Sep 2012 14:45:31 GMT
Am 08.09.2012 03:44, schrieb sebb:
> On 7 September 2012 20:46, Oliver Heger <oliver.heger@oliver-heger.de> wrote:
>> 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.
>
> BC breakage will require package and Maven coordinate changes at some
> point just before release.
Yes, I am aware of this.

>
>> 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.
>
> Not sure I follow that.
> Why would changing a dependency affect the API for Configuration?
> Does not make sense to me.
Some classes of [lang] are exposed in the public API of [configuration]. 
For instance, variable substitution in configuration files is done by a 
org.apache.commons.lang.text.StrSubstitutor object. The StrSubstitutor 
to use can be set. So switching to [lang3] will effectively change the 
public API of [configuration] in an incompatible way.

Oliver

>
>> - 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