Am 08.09.2012 03:44, schrieb sebb:
On 7 September 2012 20:46, Oliver Heger <oliver.he...@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-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
