[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] Monotone upgrade policy for the SQLite copy?
From: |
Ralf S. Engelschall |
Subject: |
Re: [Monotone-devel] Monotone upgrade policy for the SQLite copy? |
Date: |
Sat, 29 Mar 2008 21:07:08 +0100 |
User-agent: |
Mutt/1.5.17 OpenPKG/CURRENT (2007-11-01) |
On Sat, Mar 29, 2008, Markus Schiltknecht wrote:
> Ralf S. Engelschall wrote:
> [...]
>
> For the bundled sqlite variant, we should IMO switch to the amalgamation
> distribution.
As Monotone is already using its own build-environment for building the
sqlite/*.c files we instead actually can switch from sqlite/*.[ch] to
just the sqlite3.[ch] files from the SQLite "amalgamation" distribution.
>> If there is still no such policy I personally recommend a policy like
>> this (and saved for reference into e.g. "sqlite/README.MTN"): "Monotone
>> should can be upgraded to the latest version of SQLite as long as (1)
>> this SQLite version it is fully backward compatible to the old on disk
>> format (= is able to read it) and at maximum a dump/restore of the
>> database is necessary,
>
> What minimum requirement are you proposing here? Fully backward compatible
> (on disk format) *or* dump/restore?
Fully backward compatible on-disk format will be not possible in the
long-term, so as long as a dump/restore is still possible everything
should be fine. At least as long as Monotone is in heavy "development
mode" (versions 0.xx) a dump/restore is fully acceptable IMHO. But
once Monotone reached something like a version above 1.0, a full
dump/restore is IMHO only acceptable any longer for a jump between N.M.x
and N.(M+1).0 but not between N.M.x and M.M.(x+k). But we are still not
at this point in time...
> Especially when we allow linking against system libraries, we have to be
> careful and check multiple versions. Maybe even provide a "downgrade"
> feature, i.e. if a user first uses a newish system provided sqlite, then
> downgrades to the monotone provided one by building mtn from source.
> However, dump/restore should do the trick.
Yes, for those scenarious a dump/restore will be necessary.
> [...]
> Yes, there are pretty obvious, IMO. I don't think we are lacking a policy.
> We need someone to just *do* it. Are you volunteering to test monotone
> against sqlite 3.5.x? Or try integrating the amalgamation distribution?
Ok, I volunteer and will try to upgrade and test Monotone with SQLite 3.5.x
Ralf S. Engelschall
address@hidden
www.engelschall.com