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. 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. If we change the package name and artifactId back then the version should also be 1.1. Ralph
