This sounds appealing, but I was told that in an Apache open source proejct like this we can't really have checkin policies, only guidelines?
I do think having compatibility tests will help ensure that these guidelines are met, however. I didn't think about a regression test to catch massive jar file growth, that seems easy enough to add... David Kathey Marsden wrote On 10/20/05 09:46,: > John Embretsen wrote: > > >>David W. Van Couvering wrote: >> >> >>>I can add this, but to answer real quickly, at this point there are >>>no restrictions and no visible user impact. >> >>ly add a "no" between the words "be" and "visible" in the following >>sentence in the "User Visible Impact and Restrictions" sectio >>Then you should probabn: >> >>"With these guidelines in place, there should in general be visible >>impact or restrictions for Derby users." > > > > I think I would prefer to see a clear commitment (without words like > "should" and "in general" ) that: > > There *will* be no visible impact or restrictions for Derby users who > have different versions of derbyclient.jar, derbytools.jar and > derby.jar in the same JVM, unless the jars are different major > versions. If the major versions differ, classloaders need to be used > to separate the versions. > > No visible impact implies the following checkin requirements for any > common code. > > - derbyclient.jar, derby.jar, and derbytools.jar of the same major > version can continue to be mixed within the same JVM classpath without > any difference in behavior from loading these jars in separate > classloaders. > - Jar file growth is commensurate with functionality improvement. > - Replacing any jar with a jar of the same major version will not > require any user classpath changes. > > Is that what we are committing to? > > Kathey > > >
