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 "ForwardCompatibility" by DavidVanCouvering
Date Mon, 03 Apr 2006 18:35:26 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/ForwardCompatibility

------------------------------------------------------------------------------
  
       * Dropping support of JDK 1.3/JDBC2.1. Technically a regression but it seems unlikely
that by the time the community does this that there will be any demand for JDK 1.3. (We've
voted that it's ok to do this in 10.3, but someone has to scratch that itch)
  
+ Users of Derby have several options under the hopefully rare occasion that a new release
breaks their application:
+    - Fix their application
+    - Use the old release (i.e., don't upgrade)
+    - Pay someone who is supporting Derby to fix their problem.
+    - Get involved in the Derby community and suggest/provide a fix to their problem.
+    - Patch the source in their local copy of the Derby source code by reverting the fix
that causes the problem for them.
  
  == What is an Interface? ==
  
@@ -56, +62 @@

  
  This is an interface which we expect others to depend upon to remain stable enough for them
to build their own products or systems on top of.  Most of our public interfaces should be
given the stability level of Stable.  Stable interfaces should never change between minor
releases, and even between major releases changes should be extremely rare.  
  
+ Note that an interface '''must be documented''' before it can be classified Stable or Unstable.
 Any undocumented interface can only be given a Private or Private Stable stability level.
 New features can not be considered Stable or Unstable until they are documented.
+ 
  '''It is important to note that having a major release does not mean that the release ''will''
have incompatible changes to a Stable interface.  It is just that a major release is the only
time where an incompatibility ''can'' be introduced on a Stable interface'''
  
  Any changes to Stable interfaces should be documented in the release notes.
@@ -72, +80 @@

     * Incompatible change allowed in minor release (x.Y)
  
  This is usually for new functionality that we feel is experimental or unstable.  Documentation
should make it very clear that this interface may change between minor releases.  Changes
to unstable interfaces should be documented in the release notes.
+ 
+ Note that an interface '''must be documented''' before it can be classified Stable or Unstable.
 Any undocumented interface can only be given a Private or Private Stable stability level.
 New features can not be considered Stable or Unstable until they are documented.
  
  === Private ===
     * Incompatible change allowed at any time
@@ -221, +231 @@

  ||Defaults returned by {{{DatabaseMetadata}}} methods||Stable|| || ||
  ||Documented configuration defaults||Stable|| || ||
  ||Console output format for tools and network server||Private|| || ||
+ ||Debug trace outputs||Private|| ||
- ||System stored procedures||(Private?) Stable|| || ||
+ ||System stored procedures||Stable|| || ||
+ ||Query plan output as displayed by RUNTIMESTATISTICS||Private|| |There are example outputs
in the documentation but the full format of RUNTIMESTATISTICS is not document and therefore
this should be considered a private interface. '''Do we need a Private Unstable classification
for this?'''||
  
  == Other notes ==
    * Platform support

Mime
View raw message