We already have a bdbversion.txt file.
I would just use that, or is it not sufficient? I don't think it's a problem to only fix this in gramps 4.0
This is on the roadmap of 3.4 because we use 3.4 and 4.0, but users will not do that.
So it should be sufficient if 4.0 gives warning if
1/no bdbversion.txt present
2/present but older version.

If user upgrades with 4.0, he should not expect it to open with 3.4 (it will work in 3.4 anyway if the python version is the same though!).

Anyway, from the mailing correspondence, I was thinking Tim fixed this already....

Backporting bdbversion.txt writeout to gramps 3.4 is off course allowed :-)


2013/3/15 Nick Hall <nick__hall@hotmail.com>
On 15/03/13 20:51, Paul Franklin wrote:
> On 3/15/13, Nick Hall <nick__hall@hotmail.com> wrote:
>> Is there a way we can determine the bsddb version before opening a
>> table?   If not, should we create a text file containing a version, so
>> we can warn the user before an upgrade?
> If an additional file is created, why not put everything into it
> which a "gramps -L" types out (number of people, locked, etc.)?
> Just a thought.
We could create an extra file.  My question is, do we want to?

Is there a neat way of detecting that Gramps is about to upgrade the

How do we want to fix this?   It applies not only to CLI, but also to
the GUI.


Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
Gramps-devel mailing list