>>>>> "Jan" == Jan Harkes <jaharkes_at_cs.cmu.edu> writes:

    Jan> Argh, libdb4, they are at 4 already? What is the use of a
    Jan> 'data storage' if it changes about twice a year. Does anyone
    Jan> think it is reasonable to expect to read a database file that
    Jan> was created less than 2 years ago?

AFAIK libdb4 _is_ backward-compatible with everything since libdb2 at
the file format level.  They've added two new access/indexing schemes
(IIRC) and also changed the database opening call in a trivial way
(they added a couple of parameters which when defaulted to NULL work
as in previous versions) which justifies the major version bumps.
They are not forward compatible, you must rebuild old apps to use the
new access/index formats.  (Again, IIRC) the reason for the file
format incompatibility 1.85 -> 2 was to provide backward compatibility
of this kind in the future (not to mention sane error messages when an
unknown format is ecnountered).  The 1.85 format didn't provide for
future extension, guaranteeing the kind of pain Coda is experiencing
now.  Hard on you (and me!) but I think Sleepycat did the best they
could.

It does rather anger me that Debian and (apparently) Red Hat fail to
go to the trouble to create a db_dump185 that can read 1.85-format
files (AFAICT Debian's default db_dump185 is just a regular DB3
db_dump that can only read DB2 files ;-).

-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.