[twitter-dev] Re: Question about versioning

[Marcel Molina]

We do not have plans to support minor versions initially. We're going
to start with the simplest versioning scheme possible and then expand
it to include minor versions when the need arises.

So as of right now version 1 already exists, at
http://api.twitter.com/1. As for whether it should be considered
"stable", I'd say it's very close to being so. I've been using it
exclusively on my Twitter clients for several months. Since announcing
it publicly a couple weeks ago the only reports of irregularities have
been around server configuration (e.g. some requests over ssl getting
an untrusted cert error and requests for gzipped responses not being
configured correctly). As for the behavior of the API it should be
100% compatible with the non versioned twitter.com API.

On Thu, Nov 5, 2009 at 7:36 AM, DeWitt Clinton  wrote:
> Hi all,
> I'd like to sync the version numbers and release cycles of a few twitter
> libraries (python-twitter and java-twitter) up with the version of the
> Twitter API itself.  I'll admit that I've fallen way behind on
> the maintenance of each, partly because the Twitter API itself is a moving
> target (not a bad thing, just hard to keep in sync with).
> What's the expected timing of when we can rely on a stable versioned
> endpoint for v1, v2, etc, and bleeding-edge API versions?  In theory we'd do
> parallel releases on major/minor releases, and keep a dev branch open for
> the latest-and-greatest-and-beta-est version of the Twitter API.
> -DeWitt



-- 
Marcel Molina
Twitter Platform Team
http://twitter.com/noradio

[twitter-dev] Re: Question about versioning

[Jesse Stay]

Did I miss the announcement that Twitter was planning to implement
versioning?  I don't recall that.

Jesse

On Thu, Nov 5, 2009 at 11:23 AM, DeWitt Clinton  wrote:

> That doesn't quite work, as sometimes parameters and response values are
> tweaked for existing calls, not just new areas of functionality. See
> http://apiwiki.twitter.com/REST+API+Changelog for examples.
>
> For the most part things have been backwardly compatible, which is to be
> applauded.  I think all I'm requesting is what's already been announced --
> that there is an explicit version id in the API, and that those methods
> remain stable.  Then I can release a 1.0 version of the libraries that are
> hard-coded to the v1 endpoints, a 1.1 version hard-coded to the v1.1
> endpoints, etc, and a 'dev' version of the libraries against the current
> beta endpoints.
>
> We went through exactly this process in developing the Google Data APIs,
> and while my takeaway from that experience is that you can never plan early
> enough for versioning, it's still better to do later than never, which
> sounds like Twitter's current plan (good!).
>
> I'm just asking when we can plan to target explicit versions.
>
> -DeWitt
>
>
> On Thu, Nov 5, 2009 at 10:10 AM, Jesse Stay  wrote:
>
>> I don't think Twitter has versions right now - you should look at what the
>> Net::Twitter libraries for Perl are doing though.  With those, you tell it
>> which components of the library you want to include when you're
>> instanciating your initial $twitter object.  So if you want to include
>> search functionality, you tell it to include the search components.  If you
>> want to include list functionality you tell it to include the list
>> components.  Keeps it nice and lightweight for when you need it to.
>>
>> Jesse
>>
>>
>> On Thu, Nov 5, 2009 at 7:36 AM, DeWitt Clinton  wrote:
>>
>>> Hi all,
>>>
>>> I'd like to sync the version numbers and release cycles of a few twitter
>>> libraries (python-twitter  and
>>> java-twitter ) up with the
>>> version of the Twitter API itself.  I'll admit that I've fallen way behind
>>> on the maintenance of each, partly because the Twitter API itself is a
>>> moving target (not a bad thing, just hard to keep in sync with).
>>>
>>> What's the expected timing of when we can rely on a stable versioned
>>> endpoint for v1, v2, etc, and bleeding-edge API versions?  In theory we'd do
>>> parallel releases on major/minor releases, and keep a dev branch open for
>>> the latest-and-greatest-and-beta-est version of the Twitter API.
>>>
>>> -DeWitt
>>>
>>
>>
>