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 04:17:18 GMT
On 15 November 2010 04:07, Ralph Goers <> wrote:
> On Nov 14, 2010, at 7:43 PM, sebb wrote:
>> 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 <>
>>>>> 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.
> I think I'm going to go crazy soon.
> On Nov 5 you said to keep the version at 2.0 and the package names the same. James said
not enough changed and the version should be 1.1.  On Nov 7, you posted some output from
Clirr that indicated the code is not binary compatible. Based on that James recommended that
the package name and artifactid be changed.

There was also a suggestion to revisit the API changes, but that was
not followed.

> So I changed all that.  Now you are saying the compatibility problem isn't that bad,
even though we've now started changing some of the public APIs to include Java 5 generics.

No, I'm saying that if the compatibility problems can be solved, then
there's no need to change the package name.

Given that a package name change affects all downstream users, I think
we need to make sure first whether it is really necessary.

> If we change the package name and artifactId back then the version should also be 1.1.

A major version change is required if there is a binary incompatibilty.
It is not forbidden for compatible releases; given that VFS has
changed to Java 1.5 and added generics I think that deserves a major
version bump.

> Ralph

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

View raw message