Mailing-List: contact derby-commits-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Derby Development" <derby-dev@db.apache.org>
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: Apache Wiki <wikidiffs@apache.org>
To: derby-commits@db.apache.org
Date: Thu, 22 Sep 2005 04:28:34 -0000
Message-ID: <20050922042834.6363.81792@ajax.apache.org>
Subject: [Db-derby Wiki] Trivial Update of "ModuleVersioningGuidelines" by
 DavidVanCouvering

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/ModuleVersioningGuidelines

------------------------------------------------------------------------------
  
     * Deprecation guidelines and mechanisms
  
-    * Interface version publication and detection
- 
  == Guidelines for Forward Compatibility ==
  
- It is important that shareable modules are as interoperable as possible across versions
+ It is important that shareable modules are as interoperable as possible across versions.  This includes a new client of an interface being able to work with an old implementation.  Wherever possible, version X.Y of a client should work with version X.Y' of a module where Y' < Y.  If the client uses new functionality added in version X.Y of the module, it should degrade to X.Y' level functionality.  In the rare cases where this is not achievable, it should throw an exception explaining that it requires version X.Y or greater of the module (rather than an obtuse Java exception like NoSuchMethodException).
  
+ To enable this type of detection and behavior degradation, every module must provide access to its version information through a static method that returns an instance of `org.apache.derby.iapi.services.ProductVersionHolder`.  A client can then use this information to determine whether it is compatible with the module or if it needs to either degrade its behavior or throw an exception.
+ 
+ === Deprecation Guidelines ===
+ A method or an interface may be deprecated.  This is done using the @deprecated tag in the method or interface Javadoc.  A method or interface must be available for 2 major releases after it is deprecated.  For example, if it is deprecated in version 8.2, it can be removed in version 10.0 or greater.  An exception to this rule may occur if it becomes clear that there is still heavy use of this interface.
+ 
+   
+