Difference between revisions of "3.2 Roadmap"

From Gramps
Jump to: navigation, search
Line 1: Line 1:
 
This page collects possibilities for the 3.2 version of GRAMPS
 
This page collects possibilities for the 3.2 version of GRAMPS
 +
 +
==Schedule==
 +
* June 2009: database changes finished and merged back in trunk
 +
* November 2009: main goals merged back in trunk
 +
* Beginning of 2010: Release
  
 
==Policy changes==
 
==Policy changes==

Revision as of 14:16, 24 February 2009

This page collects possibilities for the 3.2 version of GRAMPS

Schedule

  • June 2009: database changes finished and merged back in trunk
  • November 2009: main goals merged back in trunk
  • Beginning of 2010: Release

Policy changes

Changes to the way developers handle the workflow. This will be decided by the core developers in the near future.

  • Required minimum pylint score? This would require all present code to at least obtain this score?
  • svn branches for database changes and main goals? Can everybody with commit rights make a branch or only admins?
  • Decision on the definition of the different parts of GRAMPS. What do we allow as plugins, views, gramplets, ... ? How do we offer the user a non-confusing image of what GRAMPS is? This starts in version 3.1 with not distributing some parts of GRAMPS that are present in the subversion repository.

Dependency upgrades

For 3.1 we have: Python 2.5 or greater, PyGTK2 2.10 or greater, Python Glade bindings, librsvg2 (svg icon view), xdg-utils Recommended or optional: GraphViz, gtkspell, ttf-freefont. Documentation is in mediawiki.

For 3.2:

  • change to PyGTK 2.12. Reason: Move away from libglade to GtkBuilder. Info: [1], example: [2]. Developers: ? - Reviewers: ?

Database backend changes

Are there features that require database change? This should happen in the beginning of the development cycle. List your requirements here. Database changes should be started in subversion branches (see commands eg here)

Suggestions:

  • event subtype: bug tracker:[3]. There is partial support for this in GEDCOM that is not present in Gramps. This addition would mean a rework of the event type system to make it more user friendly to the user, instead of the copy of GEDCOM it is now: selection of most used events, main events with subtypes, addition of iternaries as subtype to use for map display, .... Developers: bmcage - Reviewers: ?

Main goals

This section lists main goals developers want to achieve with GRAMPS 3.2. Main goals should be started in subversion branches (see commands eg here)

  • File Organization (GEPS 008): bug tracker:[4]. Developers: ? - Reviewers: ?
  • Import Export Merge (GEPS 009): bug tracker:[5]. Developers: ? - Reviewers: ?
  • Beter API documentation: bug tracker:[6]. Developers: ? - Reviewers: ?
  • rework PageView classes: bug tracker: TODO. Aim would be to split PageView and classes to it's own subdirectory, allow views to be plugins, have PersonView derive from the same classes as the other views instead of a custom class, have history in all listviews (as it was intended originally, code is half finished now), allow organized views in source/place like in present person view. Developers: bmcage - Reviewers: ?

Minor goals

This section lists minor goals developers want to achieve. Changes to plugins are normally minor goals !! Minor goals can be done by one developers alone.

  • Fully functional GeoView: bug tracker: TODO. GeoView has some way to go to be on the level needed to allow inclusion in GRAMPS. Developers: ?
  • Remove memory leaks present in glade loading code. bug tracker: [7]