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 http://db.apache.org/derby/derby_charter.html. 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 long. Kathey
