commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [math] next step
Date Mon, 08 Apr 2013 16:33:11 GMT
On 8 April 2013 13:22, Gilles <gilles@harfang.homelinux.org> wrote:

> On Mon, 8 Apr 2013 11:52:25 +0100, sebb wrote:
>
>> On 8 April 2013 08:14, Luc Maisonobe <Luc.Maisonobe@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.
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.


> Regards,
> Gilles
>
>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<dev-unsubscribe@commons.apache.org>
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message