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.
Regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
