In Gep 18 branch I pushed the database change:

* new name field, which replaces old title
* new template field to store the template, default is GEDCOM and behaviour as now
* removed title, author and pub_info. For support the get_methods are still present with a @deprecated decorator. The set_ methods are removed. The api of source is extended with get_gedcom_author, get_gedcom_publication_info and get_gedcom_title, which in effect behave as the old methods

* new name field, which replaces the old page field
* removed page field. Again, a get_page is present, which just calls get_name for you, set_page is removed. There is also a new get_gedcom_page, which is used by gedcom export and needs the source template field to produce correct results.

Upgrade/import/export are all changed, in essence the deprecated fields are stored in attributes, with the name field forming an alias used in Gramps.
You will need to remove the ini files for source and citaiton views in gramps41 folder, or there will be crashes.
Trunk family trees cannot be used as the database version is equal to the one in trunk, but different in reality.

As now trunk and GEP database are different, and I soon go on a long holiday, I would like to merge the branch back into trunk next week. Reasons:

* API source/citation/template is quite stable now. So data storage is done.
* all should work at the moment, so gep18 is functional
* trunk and gep18 can no longer be used side by side due to view changes that collide in gramps41 directory
* GUI will still change a lot. More people using it will make discussion simpler :-) Specifically things like name field unsensitive as long as checkbox to set it automatic is set, improved template selection, ... . I consider these minor things as there are still some 5 months before december when things must be finished.
In essense, the display stuff will change, but that can be done incrementally in trunk.

Note that templates can already be plugins, and the EE templates hidden via the plugin manager.

There are still large things to do which can then happen in trunk later on:

1/ although templates can be easily distributed via plugins and making a simple csv, I do want to add a user editable locally stored template editor.

2/ I'll add a 'remove' column to the csv table to indicate fields that should be asked to user, but not used in constructing the reference

3/ usability improvements

4/ actually use the new references by changing endnotes and bibliography to use the new templates

5/ if users hide EE, there is little use to use templates. We need a good basic set for common users in the Basics section

If there are good reasons not to merge back, let it be known !