Am 14.08.2011 23:28, schrieb Emmanuel Bourg:
Le 13/08/2011 20:53, Oliver Heger a écrit :
Hi,
as you may have noticed, I have started some work in order to prepare a
release (version 1.7) of [configuration]. I assume this will be the last
release compatible with Java 1.4.
So the release after 1.7 would be the code on the 2.0 branch ?
To be honest, I think the branch is a mess.
Maybe [configuration] should follow the road other components have gone
before: make the APIs ready for Java 5+, but do only limited
refactoring. Ideally, this could even be done in a binary compatible
way. However, I am not sure whether binary compatibility can be achieved
as we might want to polish some interfaces.
I plan to have a look at the current Jira issues, but I hope there are
no major issues open which have to be addressed immediately.
If possible I'd like to get CONFIGURATION-427 addressed in the 1.7
release. If it's ok to store a list of values inside a node I suggest
applying my patch without the new method in ConfigurationNode to
preserve the binary compatibility.
Feel free to commit. But are you sure there are no undesired side
effects? I can imagine that queries won't work as expected if a node
contains multiple values. Maybe some tests can be added in this respect?
The main open point is still the snapshot dependency to [vfs]. What is
the status there? IMHO it is also an option to create a release branch,
remove the dependency there, and release 1.7 without [vfs] support. It
is no problem to push out another release as soon as [vfs] 2.0 becomes
available. WDYT?
I would release 1.7 without vfs 2.0, we can still release 1.8 later when
vfs is ready.
Probably a question of time. If the vfs 2.0 release is a matter of some
days or weeks, this is no problem. The release preparations for
[configuration] will take some time, too. However, if we were talking
about some more months, I would prefer a release without vfs, too.
Oliver
Emmanuel Bourg
---------------------------------------------------------------------
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
