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

Reply via email to