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 DanDebrunner
Date Mon, 03 Apr 2006 18:52:19 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 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.
  

Mime
View raw message