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

[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 DanDebrunner:
http://wiki.apache.org/db-derby/ForwardCompatibility

------------------------------------------------------------------------------
  
  == Goal ==
  
+ Original goal (with minor re-wording)
+ 
+ The goal is to allow any application written against the public interfaces of an older version of Derby to run,
+ without any changes, against a newer version of Derby.
+ 
+ Alternate goal
+ 
  This is our goal: An application which runs against a Derby release today ''that does not depend on interfaces explicitly declared as unstable or on interfaces which are not documented'' will also run tomorrow against all subsequent patch and minor releases. We strive to minimize churn for applications migrating to the next major release of Derby.  However these migrations may entail application changes.
+ 
+ 
  
  Detailed information on [http://db.apache.org/derby/papers/versionupgrade.html Derby's versioning scheme]. 
  
@@ -209, +218 @@

  ||Class path requirements||Stable|| || ||
  ||Jar file manifest entires that define external behavior||Stable|| ||e.g. OSGi bundling now and auto-loading of JDBC driver in the future||
  ||derby.log file format||Unstable|| ||
- ||On-disk database file format||Private Stable|| || ||
+ ||On-disk database file format||Private Stable|| || http://db.apache.org/derby/papers/versionupgrade.html ||
- ||On-disk log file format||Private?|| ||Not sure if this is correct -- can this change incompatibly across point or minor releases?||
+ ||On-disk transaction log file format||Private?|| ||Not sure if this is correct -- can this change incompatibly across point or minor releases? http://db.apache.org/derby/papers/versionupgrade.html||
  ||Metadata stored procedures||Private Stable|| ||These may be used by earlier clients to implement JDBC !DatabaseMetadata calls||
  ||SQL States defined by SQL specification||Standard|| ||There may be reasons to change a SQL State at a minor release boundary; for example,if the wrong SQL State is being used.  These will be addressed on a case-by-case by the community.||
  ||Non-standard Derby SQL States||Unstable|| || ||
@@ -265, +274 @@

  If a standards body makes an incompatible change to a standard interface that we rely on, and we make the choice to upgrade to the new, incompatible revision of that standard, then, yes, we should move to a new major release.  A standards body making an incompatible change to a standard should be fairly rare, however.
  
  === If no-one made such a change, would be be having 10.14 in a number of years? ===
- Yes, possibly, unless the community has other reasons to upgrade the version.  Solaris 10 is actually Solaris 2.10.  Solaris has been at the major revision of 2 for over 10 years.
+ Yes, possibly, unless the community has other reasons to upgrade the version.