On Mon, 8 Apr 2013 17:33:11 +0100, sebb wrote:
On 8 April 2013 13:22, Gilles <gil...@harfang.homelinux.org> wrote:
On Mon, 8 Apr 2013 11:52:25 +0100, sebb wrote:
On 8 April 2013 08:14, Luc Maisonobe <luc.maison...@free.fr> wrote:
Hi Gary (and Sebb who had similar concerns),
Le 08/04/2013 00:33, Gary Gregory a écrit :
> I would only go back and bother with creating a branch when it
is
> needed. As for a repackage I would only do that if I knew for
certain
> that I want to break BC.
Yes, we need (not want) to break compatibility. This is the reason
we
had to postpone several issues. These issues change API. Typical
examples are removing packages, removing classes, removing user
public
methods, changing method signatures, puching methods upwards from
classes to interfaces, changing interfaces ...
Might be a good time to re-organise the code into external and
internal
classes.
I raised a similar concern some time ago.
Ideally one would use public/protected vs. package/private for
that, but
that's not always possible with Java.
As far as there is no overall design, I don't think that it is
realistic,
even if it would be possible.
Focus on self-consistency is often met with reluctance to correct
the
design
when it conflicts with established use.
But so long as a class is clearly marked as being internal to Math,
I
think
it's OK for the API to change at will - just as would be the case
for
changing the signtaure of a private or package method in any class.
This is obviously not the Commons policy (cf. rules akin to "Clirr
must be
clean for a minor release"). [Which is understandable from a
practical
point-of-view.]
As mentioned quite a number of times, most of the problems could be
considered
transient with a "Release early, release often" policy where we
don't
hesitate
to refactor and change the base package name. Better for developers
and no
loss
for conservative users.
Changing package name is perhaps easy for the Commons component
developer.
And if by conservative user you mean a user who does not want or need
to
upgrade, I agree.
But not so easy for the end user, who may need a bug fix in one
component,
but may not have any control over 3rd party libraries that use
Commons
components.
IIRC even Commons VFS developers had some problems with other Commons
components releases that weren't compatible.
A package name change necessarily means more than just a global edit
of the
source and recompile.
If the package rename were the *only* change, there would be no point
doing
it.
Of course. Luc gave many examples of why the name should change.
Overall, to improve the design without getting in the way of users who
happily use 3.x (and will do so forever after).
For bug fixes they will have to use "o.a.c.math4".
Or step forward and offer to maintain a (compatible) "math3" line.
There must be some other API changes that have forced the package
change.
At least some end users will also have to change their source
accordingly.
Release early, release often is not an inherently good idea - it has
some
serious drawbacks.
I have put this subject on discussion (too) many times.
My humble opinion is (still) that CM is so broad in scope that it will
remain
forever in alpha state. [Here "alpha" is not meant to related to the
quality
of the code but to the stability of the design: new functionality or
new user's
and developers' insight will question the soundness of the design. And,
without a clearly stated rationale for everything present and future,
the only
reasonable attitude is to keep evolving. The alternative is that the
cruft
will accumulate to the point where someone will deem more efficient to
start a
new library from scratch (or fork CM).]
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
