Skip to content

Latest commit

 

History

History
131 lines (89 loc) · 4.01 KB

ChangeLog.md

File metadata and controls

131 lines (89 loc) · 4.01 KB

About this Document

This serves as both the change-log and TODO list for the project. It serves to clarify what's in an (anticipated) release, as well as to direct project momentum. (Actually, the whole point is so I'll remember to update the TODOs at least once per release ;-)

At the top, you'll see project milestones (upcoming releases) and their associated TODOs. After that, you'll see a release version history in reverse chronological order. (The latest release comes first.)

Also note that the latest stable branch (the tip of maint) is usually in an as-yet unreleased status. This avoids a proliferation of single-commit patch-level version changes in the maint branch, whilst still providing access to the very latest bug-fixes

Upcoming

Unscheduled

  • Support encoding/serialization request bodies, analogous to the decoding/de-serialization for response bodies which is done in the Content class

    • This probably means reorganizing the Content class, perhaps adding another level of structure

    • Find a convenient way for the user to specify request-body content-type. Maybe add a content_type= parameter to put() et al?

    • Does GitHub support this? It should. And if so, we should use it by default

  • Create a script to pack the basic module and any given set of service-specific classes as one file

    • Separate GitHub class into a separate module

  • Rename the project, and migrate it to a new project url. At the same time, the original link should point to a stripped down version that

    a) Works perfectly for GitHub's API, unchanged

    b) Mentions the new project in the README

    c) Is updated jointly (at release milestones) by uploading the result of pack-script GitHub (The pack-script is described above.)

    Motivation

    The project is referenced from GitHub's official list of API clients. Ergo, anything not pertaining to GitHub's API doesn't really belong at that URL — it's distracting. Users should be made aware of the generic version without being forced to migrate.

    Besides, the updates could easily be automated via a post-push hook that walks the master/maint history in the main project; and thereby be supported indefinitely without fuss

  • Actually support OAuth

  • TODO: Use a real, venerable test framework — maybe unittest

  • Support Request/Response compression. Here's a great tutorial

v2.0

  • Refactor code-base

    • In particular, we need to spell "GitHub" correctly: Github -> GitHub
    • Convert most identifiers from under_scores to camelCase (An exception will be the media-type converters in Content (e.g. application_json))
    • Fix anything else that makes me squeamish

  • Support XML de-serialization. Python has (I think) built-in support for this

v1.1.1

This is the upcoming maint release. Even though it hasn't been released yet, it is the preferred stable branch because it includes fresh bug-fixes

  • Python-3 support for authenticated sessions

Release

v1.2

  • Revamp the internals, adding extensibility and flexibility. Meanwhile, the external API (i.e. via the Github class) is entirely unchanged

  • New test-suite. It is ad-hoc and primitive, but effective

  • Generic support for other REST web services

    • New top-level class (API)
    • Github is now a subclass of the API class, and is the model for creating new subclasses
    • Facebook and SalesForce subclasses created, allowing (basic) access to these web services

v1.1

  • Includes the version in the user-agent string

v1.0

  • Has a version number. (Yippie!)
  • First more-or-less stable version