Hi,
there is a request [1] to publish a release of [configuration] which is
compatible with the newest version of [lang]. This really makes sense, I
am myself in a situation where I have to include [lang] in two versions
(2.x and 3.x) due to the dependency to [configuration]. Unfortunately,
switching to [lang] 3.x cannot be done in a binary compatible way
because some types are exposed in the public API of [configuration].
I doubt that we will come up with a revised and clean version of a
Configuration 2.0 API sometime soon. So what are our options? Should we
push out an intermediate 2.0 version which is pretty close to the
current trunk with some incompatible changes? (What other improvements
could such a version contain which can be implemented with a reasonable
effort?) The major API redesign would then be done for version 3.0. IMHO
this would fit well to the release early/release often paradigm.
Independent from this, it would be good to start a discussion about how
a next-generation configuration API could look like.
What are your opinions?
Oliver
[1] https://issues.apache.org/jira/browse/CONFIGURATION-462
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
