monotone-devel
[Top][All Lists]
Advanced

[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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]