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