commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles Sadowski <>
Subject Re: [Math] What's the problem with interfaces?
Date Thu, 31 Mar 2011 14:41:50 GMT

> No. There are always times, when too many stuff piled up that requires an 
> API change. But then you may have more radical changes and combine it with 
> e.g. new (incompatible) JDK features. New digester is a very good example of 
> it. But you have to make very wise decisions about the new API to keep it 
> stable again for a maximum time.

My intention is not to blame anyone for past decisions; they were certainly
convinced they made wise decisions.
However, I have looked at some of the code, and it was obvious that the
some of the design could be improved. Again I'm not criticizing the math
features but e.g. code duplication, overlapping functionality, similar
functionalities implemented in dissimilar ways; all little things that add
up so as to make the code more difficult to understand and maintain.
I stress again than CM is probably not like other Commons projects in that
its code base is much larger, which makes it all the more important to have
it consistent throughout.

I insist that once the API is consistent, it will naturally (and not by
veto) not have to change much in the future. [And if it needs be, the work
will be easier because all the changes will be similar.]

> > So, my opinion is that users will prefer a product
> > that continues to improve rather than something that is
> > backward-compatible. I'm one of those. If not, I'd be content with what is
> > there and would not feel the need to contribute.
> Problem is that it does not match the business requirement.
> See, when I am cleaning the apache stuff out of my local repo and start a 
> complete build of or products and components, I end up with quite every 
> available version of commons-lang, commons-io, commons-collection, etc. in 
> my repo again. However, *we* do only use one of those versions i.e. all he 
> other versions are pulled by 3rd party stuff. Therefore I have to praise my 
> fellow committers here at Apache, who made it possible to upgrade all those 
> artifacts and all the stuff will simply run regardless of the original 
> version they were dependent on.
> Now, commons math might not have that wide-spread usage up to now, but the 
> new version has been proposed and recognized and as soon as companies start 
> to build products on top of it, you argumentation simply no longer applies. 
> Not all of those products will upgrade at the same time, but a user might 
> have to use two such products (depending on incompatible math releases).
> Therefore we have the policy to rename package and artifactId for major 
> versions, at the price of annoying upgrades for our users. But they will at 
> least not face the situation above. However, such annoying upgrades should 
> not happen too frequently, because it is effort.

I thought that this was settled these rules:
 1. minor releases are backward-compatible,
 2. new major releases can live with older releases (thanks to a different
    base package name).

 1. users who don't touch their own code can use the last release compatible
    with it;
 2. users who want to use new features will, by definition, have to touch
    their code and thus will "import" what they want, either from the old
    base name packages, or from the new ones.

If I'm not mistaken, this is the answer to the "business requirement".
And it does not prevent us from evolving the code as often as necessary
("math3", "math4", ...).

> >> > Part of the real problem (as shown by the amazing amount of done and
> >> > undone work for 2.2) is that you (collectively) want to do too many
> >> > things at the same time (lots of changes *and* few releases). To be
> >> > clear, the problem is not the "lots of changes" part (which you would
> >> > like to "solve" by vetoing future compatibility-breaking improvements).
> >> > Note that the following is not a criticism of CM (which has many
> >> > features etc.) but some of the code that I've seen (in the parts which
> >> > I've more closely looked at) do not make me think that it is mature
> >> > enough that one can say "That's it!" and stick with the design forever.
> >> > Again, all this (e.g. removing duplicate code and refactoring the
> >> > design) can be considered unimportant and swept under the carpet but
> >> > IMO *any* cleanup is good as it will contribute to the overall
> >> > robustness and maintainability.
> >> > Half-baked design will continue to itch.
> >> 
> >> Half-baked upgrade strategies also.
> > 
> > Unforunately CM currently does not have the resources of its ambitions
> > concerning the upgrade strategies! That implies that some expectations
> > must be dropped: IMHO, code improvement is, at this time, more important
> > than upgrade easiness.
> We disagree here obviously, but see also Phil's answer on this.

The more we defer the consistency goal, the more code will need changes, the
lesser people will want to do it, and the overall quality will probably
suffer. Then, there will be a day where some potential contributors will
turn away rather than figure out the mess.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message