db-derby-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Db-derby Wiki] Update of "SharedComponentVersioningGuidelines" by DavidVanCouvering
Date Thu, 20 Oct 2005 22:03:47 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Db-derby Wiki" for change notification.

The following page has been changed by DavidVanCouvering:
http://wiki.apache.org/db-derby/SharedComponentVersioningGuidelines

------------------------------------------------------------------------------
  
  == User Visible Impact and Restrictions ==
  
+ With these guidelines in place, there will be no visible impact or restrictions for Derby
users.  
+ 
+ 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.
+ 
- With these guidelines in place, there should in general be visible impact or restrictions
for Derby users.  The only exception is if for some reason (and this is to be avoided) a change
is made between major revisions that is not compatible, then if the user is running in a mixed
version environment in the same VM, he or she should attempt to ensure that the jar files
from the newer version are loaded first.  If for some reason this is not possible, the user
will need to separate the two versions by using separate classloaders within the same VM.
+ The only exception is if for some reason (and this is to be avoided) a change is made between
major revisions that is not compatible, then if the user is running in a mixed version environment
in the same VM, he or she should attempt to ensure that the jar files from the newer version
are loaded first.  If for some reason this is not possible, the user will need to separate
the two versions by using separate classloaders within the same VM.
  
  == Testing Impact ==
  
@@ -102, +115 @@

    * Build common component unit tests against the new release and test against jar files
from old releases (backward compatibility tests)
    * Build common component unit tests from old releases and test against jar files from
the new release (forward compatibility tests)
  
- Any incompatibilities between patch and minor releases should be considrered bugs.  Any
incompatibilities between major releases should be documented.
+ Any incompatibilities introduced between patch and minor releases should be considered a
regression.  Any incompatibilities between major releases should be documented.
   
  == Introducing New Shared Components and Shared Packages ==
  

Mime
View raw message