Jörg Schaible a écrit :
IMHO we should define what we want to reach. Adding a method to an interface
does not break *binary* compatibility of existing code. The method is simply
not called. However, a client will have to implement the new method, if CConf
is a compile time dependency *and* he
On Tue, Jun 23, 2009 at 3:44 AM, Emmanuel Bourg wrote:
> Yes configuration2 will be incompatible, it's a complete refactoring of the
> API. The package was already changed. My concern is about the artifactId
> causing a confusion on the actual version of the artifact.
We're all going that route
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at gene...@gump.apache.org.
Project commons-email has an issue affecting its community integration.
This issue
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at gene...@gump.apache.org.
Project commons-configuration-test has an issue affecting its community
integrati
James Carman a écrit :
Is configuration2 binary incompatible with configuration (1)? If it
is, then you should consider changing the package name and using:
artifactId: commons-configuration2
groupId: org.apache.commons
This would be for consistency's sake.
Yes configuration2 will be incompa
