Oystein Grovlen - Sun Norway wrote: > I agree that soft upgrade has a value, but I think you give soft > upgrade credit for things that are actual not provided by soft upgrade. > Just a few somewhat disjointed but relevant thoughts before I sign off of this discussion for a while, because I need to fix some bugs.
First of all I want to say that there is a great dependence on soft upgrade in the installed user base so if the community decided to deprecate soft upgrade (which I am strongly against) it would need to be just that a deprecation and some solution to the current usage models would need to be found in advance. So this is not a 10.2 discussion. But a few things to think about. Many applications have their own soft upgrade model where they allow you to downgrade if there was an issue with the upgrade. If we take the example of the email client that is moving from Derby 10.0 to Derby 10.3, they cannot implement their own soft upgrade if we do not provide that capability in Derby. In the application server environment there is a a tangled web of Derby versions. Many applications test and ship with one Derby version and end up running in an application server with with another. We do not yet support loading multiple derby versions in the same JVM, so the applications are all tied together. Sometimes there are scenarios where two JVM's will access the database at different times, for instance an IDE running at one version accesses the database and then it is used in the application server environment. In terms of being able to revert, I am not so worried about corruption by the new version. I am worried about application compatibility. But like I said not a 10.2 discussion. Let's pick it back up next release when there is less time crunch. Kathey
