Øystein Grøvlen wrote: > > I think it is good to have soft upgrade as part of an upgrade path in > order to be able to revert to the previous version in case of > problems. I am bit more concerned about recommending users to run in > soft upgrade more or less permanently since this mode is much less > tested than a standard configuration. > I think often the users don't even realize they are running in soft upgrade mode because for the embedded driver client and server are the same thing. Folks tend to access their databases from different applications using different versions of Derby. Take this scenario.
I am a developer and I tend to go back and forth accessing my database between my IDE and App Server. My IDE bundles Derby 10.1 My App Server bundles Derby 10.1 I decide to upgrade to the latest version of my IDE with Derby 10.3 My App Server doesn't yet officially support 10.3 so is still running at 10.1 - With soft upgrade it just works (nice). - With no soft upgrade from 10.1 to 10.3 and requiring user intervention, I realize I can't use my new IDE until I can upgrade my database and App Server (not so nice). - With automatic hard upgrade I find I can no longer use my database with my App Server. (not very nice at all). Similar situations happen if someone tries out a new gui database browsers or some other tool on their database. I agree that we should find ways to encourage users to move up their data as well as their software. I see it very much like upgrading your jdk. jdk 1.6 should read the old byte code. Derby should read the old databases. You should always be able to plop down new jars, have things work fine and be able to go back to the old version if you want, but as you say, folks should be encouraged to move along, maybe a warning would be good if you are more than one version behind. Kathey
