db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kathey Marsden <kmarsdende...@sbcglobal.net>
Subject Re: Soft Upgrade and Downgrade
Date Tue, 21 Mar 2006 15:40:46 GMT
Rick Hillegas wrote:

> 4) What is the customer problem solved by Soft Upgrade?

Soft upgrade solves  many  problems for users , support and
development.  It:

-  Minimizes end  user intervention in accordance with  Derby's charter
    which calls for ease of use and zero administration for end users.
-  Encourages upgrade and reduces the need to port fixes to old releases.
-  Provides applications, embedding  or including Derby  a scalable
deployment option for distributing  new versions of Derby.

Derby is normally embedded or included in applications and the jars get
distributed on cd or by download but the data does  not. The databases
sit out at potentially millions of user sites, so it is important to
provide a seamless  revertible upgrade.    Keeping our super easy and
revertible upgrade at http://wiki.apache.org/db-derby/UpgradingTen 
means a lot of work here but is worth it because whatever demands we put
on the end user or application developer can get  multiplied by millions.

Some examples:

*Derby in an IDE or  Application Server:*
In these environments the application being upgraded controls the Derby
version but doesn't know anything about the databases it is upgrading. 
In the application server case they are also implicitly upgrading
applications they know nothing about. Sun puts Derby in J2EE and
NetBeans.  Presumably  Sun would like to ship 10.2 and in a later
version 10.3.  Whatever upgrade implications we thrust upon the end user
are going to trickle down to every person that downloads J2EE or
NetBeans and then potentially to the users of whatever applications are
deployed on J2EE or developed with NetBeans. 

*Derby in an embedded environment:*
Take the example of an email application.  The makers of this software
want to make a new release with Derby 10.3.  (Their last release was
with 10.1).  They don't have any real changes to their application that
need the new functionality and know that this upgrade will impact the
Inbox's of  hundreds of thousands  of users.   They have a requirement
that users be able to revert to the previous version if they choose
without restoring their data.  They need soft upgrade of Derby or have
to stick with 10.1.    (This example was inspired by IBM's current
effort to upgrade Lotus Notes for every one of  IBM's 300,.000
employees.  I am not actually sure how or if Derby soft upgrade fits
into the implementation of that).

*Derby in Support*
Currently IBM has 80 products and projects that  use Cloudscape (Derby)
and include it with their distribution.  I am not sure how many copies
of  Derby that is at end user sites (I always think in the millions to
try to understand the scalability issues).   We roll up fixes and
encourage our  internal  customers to upgrade early and often and tell
them that upgrading to the new jars should have no impact on their
application if they use the public interfaces.  A super easy upgrade and
ensuring compatibility is key to receptiveness to rolled up fixes.   If
we did not have this, they would demand one off patches and  we would
have to port many patches to old versions.

There are many other examples too such as multiple components running in
the same jvm and sharing a derby version, but this email is getting too


View raw message