Planned API/ABI breaks

We would like to get in as many of the remaining necessary API breaks as possible in the 0.5.x series and have as few as possible through 1.0. A few fundamental breaks are saved for a hypothetical Folks 2.x (which we have no immediate plans to start, but will after Folks 1.x is essentially feature-complete and/or requires fundamental changes for important features).

The following groups are named after their GNOME Bugzilla milestone (the last two of which have not yet been created).

folks-0.8 milestone (after Gnome 3.2)

These are to be finished during 0.7.x, with the 0.8.0 release after Gnome 3.2

• Add generic {enum/well-known string -> display string} maps to Folks (bgo#652671))

• support search-based contact retrieval (bgo#646808)

• lazy-loading attributes (bgo#648805)

• Folks dummy backend (bgo#648811)

• better handle backends that require polling (bgo#643718)

• move to commit-based contact modifications (bgo#652659)

• examples (bgo#652667)

• tutorials (bgo#652668)

• QtFolks test suite (bmc#16787)

• location support (bgo#627400)

• make EmpathyContact unnecessary

  • the main goal is to ensure that we've got all our basic use cases covered for Individual and Persona

folks-2.0 milestone

These are meant to be finished during the 1.90.x series with stable releases continuing in 1.x. The final release will be 2.0.

These goals are very long-term (there are no immediate plans to move on to Folks 2), since they generally require significant API and/or behavior changes.

• support representation of Personas before they've been committed to their backend
  • mainly intended to simplify the ugliness that is involved in tracking a details hash from the initial add_persona_from_details() call to the success/failure of adding a Persona
• make Persona edits and potentially link/unlink batch operations

  • ie, add PersonaStore.commit()

  • this maps better to address books and high-latency services (like those behind libsocialweb)

• treat attributes more generically, as in QtContacts

  • eg, add functions like:

    • T get_detail<T> ()

    • Set<T> get_details<T> ()

      • this may need to be a group of functions to handle both ordered and unordered details without excessive allocations
  • have the *Details classes inherit from a common ancestor

• GPG backend and associated new interfaces (bgo#652662)

Past breaks

This is non-exhaustive - see the NEWS file.