On Thu, 8 Jan 2015 07:53:06 -0500, Gary Gregory wrote:
On Thu, Jan 8, 2015 at 6:17 AM, Gilles <gil...@harfang.homelinux.org>
wrote:
On Thu, 8 Jan 2015 01:25:42 +0000, sebb wrote:
On 8 January 2015 at 00:43, Gilles <gil...@harfang.homelinux.org>
wrote:
On Wed, 7 Jan 2015 14:46:19 +0000, sebb wrote:
On 7 January 2015 at 08:23, luc <l...@spaceroots.org> wrote:
Le 2015-01-06 23:13, Gilles a écrit :
On Tue, 06 Jan 2015 23:10:33 +0100, Gilles wrote:
Hi.
Do we head towards 4.0, starting to implement the dreaded
breakings? ;-)
+1, +1, +1, +1 !!!
To be serious, yes, we are really stuck by now and several
pending
changes should be done. We talked about fluent API for
optimizers
and it was too much too squeeze without breaking API. I
attempted
the same for ODE, and here again it was postponed as it touched
user level interfaces.
I would even say that we should from the beginning change the
top
level package name to 4.0 so users can test earlier the changes
as
we prepare the next version, using only one feature at a time
and
preserving the older release for the other features.
That needs to be done carefully to avoid creating jar hell.
What exactly are you proposing here?
Are you referring to SNAPSHOTs only (in which case caution is
only
advisable)?
If you are proposing to release jars with the new package name,
then
this needs to be done in a separate jar with new Maven coords.
It would be possible to gradually add more packages to the new
jar as
the original ones are converted.
IIUC, we'd change the top-level package in "trunk".
[Not releasing anything. Beta-testers would need to check out
(i.e.
"clone") the source repository and compile the library by
themselves.]
If you only used the new package on the updated API it would be
more
obvious what was the proposed new API and what was old.
Pushing this further, couldn't we provide two top-level packages
already
in a backward-compatible release? I.e. in, say, CM 3.5, there would
be
o.a.c.math3 -> all the existing code + bug fixes
o.a.c.math4 -> redesigned bits + new features
This sounds like a recipe for jar hell. We have to think about a
large app
with dependencies on both math3 and 4, meaning both jars are on the
CP and
in use.
Why would someone keep both JARs in the CP, if one contains everything?
A problem I could see is that classes from math3 could be picked from
the
old JAR whereas some bug would have been fixed in the new JAR only.
The contents of both JARs would be compatible (the same actually), so
there
is no hell.
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org