commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <>
Subject Re: [VFS] change of package name breaks Gump
Date Mon, 15 Nov 2010 03:43:06 GMT
On 15 November 2010 02:08, Ralph Goers <> wrote:
> On Nov 14, 2010, at 5:51 PM, sebb wrote:
>> On 15 November 2010 01:38, Ralph Goers <> wrote:
>>> On Nov 14, 2010, at 5:34 PM, sebb wrote:
>>>> IMO it's important to ensure that the package change really is necessary.
>>> Somehow I thought that was accomplished by the last release candidate failing
to get the required votes due to the package name not being changed.  If the recommendation
had been made to make the API binary compatible I would have done that instead of going and
renaming the package. I'm getting tired of wasting my time.
>> AIUI, the root cause of the failure was due to the binary incompatibility.
>> Change of package name is one solution.
>> I don't think it's necessarily the best solution here.
>> It may well turn out to be fairly easy to keep binary compatibility -
>> or indeed maybe some API breaks are in classes/methods that are not
>> intended for external use.
> How do you intend to determine this?

The Gump tests should help here - if they don't break with the version
pre-package name change then obviously the changed API is not used by
the current set of downstream users.

However that's just a start.

There may be other changes that are acceptable breakages, e.g.

ERROR: 7009: org.apache.commons.vfs.util.UserAuthenticatorUtils:
Accessibility of method 'public UserAuthenticatorUtils()' has been
decreased from public to private

That should be OK, because the class only has static methods, so
should not be instantiated.

Seems to me it's a balance between being 100% compatible and forcing
100% of downstream users to change their code.

For example, if a public static field represents a constant, but the
final modifier was accidentally omitted.
Adding final will break compatibility, but any code that changes the
constant is wrong and needs to be modified.

If we manage to end up with a set of "acceptable" API changes, then a
version change is warranted, but I think we don't need to change
package name.

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

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

View raw message