3.4 Roadmap

From Gramps
Jump to: navigation, search


(Needs Updating)

This page collects possibilities for the 3.4 version of GRAMPS

Schedule

  • end of 2011: decision of the final 3.4 Roadmap (this document).
  • large remaining features should be committed into trunk by 10 jan 2012.
  • after 10 jan 2012: focus on cleanup, minor 'papercuts', bug fixes.
  • 20 feb 2011: a beta release, creation of branch34. Trunk becomes development for 3.5 but major commits should wait till end of feb.
  • Somewhere in March 3.4.0 is released.

Policy changes

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

  • A required minimum pylint score of 9.
  • Every main goal and database change needs at minimum one developer and one reviewer. We need to avoid situations as with 3.0/3.1 where large code changes where left only partially finished. If the developer drops out, the reviewer can or take over and fix things up, or revert the changes. If there are two developers then it suffices both are also reviewers.
  • svn branches for all large changes that requires multiple checking over a period of time during which the code will be broken (eg database changes and large refactoring). It is mainly up to the developers to do this or not, but this should make it clear how main changes can be added to the codebase without disrupting development of other people for a long period (which should be avoided). See commands eg here. Developer to write this policy: ?
  • 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. Developer to write this policy: bmcage. First scribles: GEPS 012: Ecosystem_definition
  • Developers must add Docstrings for GRAMPS API documentation to source code.

Dependency upgrades

Gramps 3.1

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.

Gramps 3.2

For 3.2:

  • change to PyGTK 2.12. Reason: Move away from libglade to GtkBuilder. Info: [1], example: [2]. Developers: ? - Reviewers: ?
  • keep python 2.5 compatibility, while preparing for python 3.x.

Reason: At the moment there are no features of the 2.6/7 version GRAMPS needs that require python 2.5 support to be dropped. Version 3.2 will however be the last GRAMPS version on python 2.x, with the next version of GRAMPS (3.3) being python 3.x only. For that reason, the move to python 3.0 needs to be prepared. For this we need the support that python 2.6 offers. That is, people should start to run GRAMPS with:

  python -3 gramps.py

which will print out depreciation warnings for all syntax that is not compatible with Python 3.0. The goal is then to clean up all Python 3.0 depreciation warnings using the new functionality that python 2.6 offers for this, while still providing fallback for python2.5 (using eg __future__ module and try, except blocks). Should somebody come forward with an important improvement that requires python2.6, or if removing the warnings of python -3 is impossible with backward python2.5 compatibility present, keeping python2.5 compatibility can be dropped after talking it through on the devel list. In other words, support for python2.5 should not be dropped without giving it a try first. Developers: All

  • it appears there is a drive to use enchant for spell checking. The API is better than gtkspell and has a python interface. We should investigate if we should not move entirely to this package and deprecate gtkspell. At a minimum we will look into adding enchant as a possible spell checking backend to GRAMPS, using it when installed. Packagers could then choose to let GRAMPS depend on enchant or gtkspell (part of gnome-extras now). Developers: Benny, Status: enchant is working

Gramps 3.3

For 3.3:

  • Only support Python 2.6 or later (configure.in, gramps.py, windows/builder/gramps2.nsi)
  • Update Python 3 Deprecated list ?

Gramps 3.4

For 3.4:

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 if disruptive (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 itineraries as subtype to use for map display, .... Developers: bmcage - Reviewers: ?

Main goals

This section lists main goals developers want to achieve with GRAMPS 3.3. Main goals should be started in subversion branches if the user wants to collaborate or use version management (consider svn-git if needed) (see commands eg here)

...

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. Partially finished 3.2 features might be completed in 3.3 and backported to a 3.2.x version if there is support for this in the community.

  • (remain roadmap 3.2) Remove memory leaks present in glade loading code. bug tracker: [6] - these changes might be backported to 3.2 depending on the code size. Developers: Benny, gburto01.
  • (remain roadmap 3.2) GEDCOM import error/warnings report. bug tracker: [7] - provide a report of GEDCOM errors and warnings after import to show the user what information has not been imported. Developers: kulath.
  • (remain roadmap 3.2) First version of Gramps on-line webapp: A multi-user, collaboration-focused version of Gramps. Based on Django Python web framework tools. See GEPS 013: GRAMPS Webapp. Developers: Doug B. and Kathy M.
  • Update Graphical reports. [8] Developers: Graig A.
  • Use new Exporter feature on reports or proxies support on reports. bug tracker: [9]
  • Clean-up see Python 3 Deprecated (python 3)
  • Fix bug on 3.3 roadmap and last remain issues for 3.2.
  • Feature Requests:
  1. Addon:Graphical_Reports#Display_formatting: Graig A.
  2. Lunisolar calendar support ?