Difference between revisions of "5.1 Roadmap"

From Gramps
Jump to: navigation, search
(Pull requests for significant changes)
(Schedule)
Line 2: Line 2:
  
 
==Schedule==
 
==Schedule==
* 31 Dec 2018 Agree final roadmap (this document).
+
{| class="wikitable"
* 15 Apr 2019 All large features should be merged into master.
+
|-
* 15 May 2019 Feature freeze.
+
| 31 Dec 2018 || Agree final roadmap (this document).
* 01 Jun 2019 String freeze.
+
|-
* 15 Jun 2019 Final release.
+
| 15 Apr 2019 || All major features should be merged into master.
 +
|-
 +
| 15 May 2019 || Feature freeze.
 +
|-
 +
| 01 Jun 2019 || String freeze.
 +
|-
 +
| 15 Jun 2019 || Final release.
 +
|-
 +
|}
  
 
==Policy changes==
 
==Policy changes==

Revision as of 22:14, 24 March 2018

This page collects possibilities for the 5.1 version of Gramps

Schedule

31 Dec 2018 Agree final roadmap (this document).
15 Apr 2019 All major features should be merged into master.
15 May 2019 Feature freeze.
01 Jun 2019 String freeze.
15 Jun 2019 Final release.

Policy changes

Project governance

At present, we use a benevolent dictator model. Thr BD defines the project's srategic direction and has the final say in decisions. Do we wish to change this?

Do we want to introduce a voting process for significant changes? If so, who gets a vote?

Perhaps we should introduce a committee to make decisions?

The following web pages are worth reading:

Procedures for branch merging

Currently the core gramps50 branch is occasionally merged into master. This process seems to have been a success, but we need to review it.

Do we want to extend it to the addons repositories?

Who should merge the branches?

When should they be merged?

Pull requests for significant changes

Always using pull requests for most changes has been proposed previously and rejected [1], but we can discuss it again.

What changes should require a pull request?

Who should be allowed to merge a PR?

Should the submitter be allowed to merge the PR?

How long should a PR remain open for reviews, comments and testing before merging?

Dependency upgrades

  • Python 3.5
  • Gtk 3.18

Database model changes

Are there features that require database change? This should happen in the beginning of the development cycle. List your requirements here.

  • Enhancements to the place structure to support GEDCOM-L
    • Allow multiple place Types with date for each
    • Deal with 200+ place types
    • Allow multiple postal codes and other attribute like data, with date for each
    • Allow places to have attributes (for above)

Major goals

This section lists main goals developers want to achieve. Major goals should be started in a GEPS branch. Major goals require a developer and a reviewer.

  • GEPS043 Improving GEDCOM support for Places

Minor goals

This section lists minor goals developers want to achieve. Minor goals can be done by one developer alone.

Suggestions:

  • Add citations and attributes to notes Sources on notes previously rejected. [2]
  • Some "attributes" we have currently don't match up well with Gedcom When Gramps originally was conceived, these attributes did not have dates, places, and media attached (Gedcom did not have these either). More recent versions of Gedcom allow this. Dated attribute would help, or just make these into Event/Fact types.
  • Change links in notes to hard-references Decided against in original design discussion. [3]
  • A method to mark objects as "used" TODO tagged items work like this now, maybe another standard tag?
  • A way to attach objects to the database itself Something like the "Researcher"/"Database owner" but including other data.