On 15 November 2010 04:07, Ralph Goers <ralph.go...@dslextreme.com> wrote: > > On Nov 14, 2010, at 7:43 PM, sebb wrote: > >> On 15 November 2010 02:08, Ralph Goers <ralph.go...@dslextreme.com> wrote: >>> >>> On Nov 14, 2010, at 5:51 PM, sebb wrote: >>> >>>> On 15 November 2010 01:38, Ralph Goers <ralph.go...@dslextreme.com> 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. >> > > 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: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
