When upgrading from a 1.1.nnn version to 1.2.nnn is steem reasonable to expect at least some compatiility problems.
I don't know Thomas's model for major.minor.build/patch, but suspect the minor changes will be substantial enough to break compat., like with PG My and others. And the build/patch version should be considered unstable until a number comes along that he/we feels is release quality (and further revision to its build # become "patches")... then, new features and unstable branches go into a new minor number with its build starting at 001. I feel your pain for concurrency of the old/new db and migration. In a project I'm working on, I've changed to using version numbers inside the package names so that two different minor (or major_minor) version can coexist at runtime; in this case it would allow you to read from the old db and write to the new (possibly update both data stores until the user turned off the option in your app). I also recall being "confused" by fact that "minor" version increments are the ones that break compatibility, not just the major ones... if you are using PG anyway :-) But I actually like that method better since major version changes can (should) denote, much more drastic API or even legal/licensing changes.. On May 24, 2:50 am, Soupdragon <[email protected]> wrote: > We've been using an old version for about 4 years now and obtained > reasonable stability. Recently I, rather rashly as it turns out, > decided to move us to a more recent version, which happened to be > 1.1.107. It's been a bit of a disaster, compounded by the coincidence > of a lot of database changes at the same time the upgrade went out. > > We have about 40 installations out there on laptops which are not > especially accessible to us. We either have to publish update scripts > or access the machines through LogMeIn. > > We've hit bugs in our synchronisation process, seemingly relating to > btree problems. > > Moving to the "latest stable" version would be a problem because it > would require all the existing databases to be rebuilt in the page > file format. > > Returning to the old version is blocked because the database, once > opened by 107, will not open using the old library. > > I decided to move those with the worst problem to 1.1.119, figuring > that the last release of 1.1 would likely be the most stable version > guaranteed to use the old database format and, hence, be compatible > with the existing database files. > > Now I've hit another bug in 119 this time in deleting records, which > is probably > > http://www.mail-archive.com/[email protected]/msg02724.html > > This is getting pretty embarrassing, especially since I made the > decision to pick H2 in the first place. I desperately need a reliable > version which will handle the old data file format. > > The frequency with which new releases of H2 seem to be coming out > recently is, frankly, alarming. > > -- > You received this message because you are subscribed to the Google Groups "H2 > Database" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group > athttp://groups.google.com/group/h2-database?hl=en. -- You received this message because you are subscribed to the Google Groups "H2 Database" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/h2-database?hl=en.
