On 8 September 2012 15:45, Oliver Heger <oliver.he...@oliver-heger.de> wrote: > 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.
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-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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
