[Db-derby Wiki] Update of "ForwardCompatibility" by DavidVanCouvering

[Apache Wiki <wi...@apache.org>]

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