commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [configuration] Plan for 2.0
Date Sun, 09 Sep 2012 12:26:01 GMT
On 8 September 2012 15:45, Oliver Heger <oliver.heger@oliver-heger.de> wrote:
> 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.

That seems very fragile. There has to be a better way to handle that.

Fixing it will break the API (once), but at least the API will then be
stable, regardless of what happens with LANG.

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

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


Mime
View raw message