2008/4/5, Brian Matherly <firstname.lastname@example.org>:
> >> I've identified a couple of changes that need to
> be made to the storage
> >> of
> >> dates, and I see that I can add that code to
> src/gen/db/dbdir.py in the
> >> gramps_update_14() method. But, given some
> people have already run this
> >> code, what is the proper way to add some more
> changes to version 14?
> > Yes, gramps_update_14() is the place. Whoever run
> the code already
> > will have to scratch his databases. Trunk isn't an
> official version.
> Ok, thanks. I'm going to put a little code in there
> to deal with
> micro-versions (13.1, 13.2) for now (especially
> since we are in
> transition, and if you accidentally open up your
> good DB it basically
> destroys it.)
This seems unnecessary. Trunk is *always* in
transition. People need to expect that.
Indeed, incremental updates is not ok, if you start it, it puts pressure on future developers to do the same, which means extra work, extra testing, all for no gain.
However, there is a real need not to mix 'good' family trees from trunk ones, and there is no need to keep databases around that are not workable anymore.
So, would it not be better to separate default trunk database path from gramps30 branch database path? Only when a trunk branch will become separated as eg a gramps 32 branch should the default position point to normal position again, and can the full upgrade of the a family tree be proparly tested. We could use .gramps/trunkgrampsdb.
In the meantime, to test, developers can move directories, or hard code database path in the preferences.
One could even argue that after a trunk db change, first time gramps is run again you get the message: 'Deleting all trunk databases as db change happened. Abort and revert to revision ... if you need to first export the family trees to gramps xml format."
>I think I'll also add a warning about
> "getting ready to
> automatically upgrade your database; are you sure?"
Now this is a good idea. Also, it would be a good idea
to disable automatic database upgrade in trunk.
it has no use to load a database if not upgrraded, so this disabling should also mean it never gets loaded.
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Register now and save $200. Hurry, offer ends at 11:59 p.m.,
Monday, April 7! Use priority code J8TLD2.
Gramps-devel mailing list