Skip to content

ChangeLog.md

Latest commit

 

History

History
151 lines (106 loc) · 4.96 KB

ChangeLog.md

File metadata and controls

151 lines (106 loc) · 4.96 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 reusing TCP connections, and "pipelining" of requests, a la RFC 2068, Sect 8.1, L2377

    • The user must ask for pipelining, and supply a callback function to be called after a response is received.
    • Rename Client.request() -> Client.addRequest() (or such)
    • Have Client.addRequest() check whether a persistent connection is wanted, and save the entire request in a Client.pendingRequests list in that case
    • Create a new Client.sendRequests() method which the user may call to send all requests up the pipeline. (It should work even if the server does not support pipelining)
    • Call the user-supplied callback whenever a request is received. There are some concurrency issues here, and we may elect to call the callback only after all requests are received.

  • 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

  • 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

  • Parse Content-Type header correctly; make a dict of the parameters (Content.ctypeParameters) available to the media-type handlers

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