Client defaults to requests without version param

[octopi]

When a client is instantiated without a version param, it defaults to making requests without a version. This has been deprecated behavior for some time and soon the API will stop supporting requests without a version and return an error instead of an actual result. Please take some time to update your library to support this so that other developers using your library have the opportunity to upgrade to a working version.

[baztokyo]

App should specify the API version you want to use meaningly and library should not be set it automatically, I think. Otherwise App might behave the developer did not intend. (For now the API returns the deprecated error, but you can use it.)

[octopi]

You're correct that the Foursquare API currently returns a deprecated error along with an actual response; however, the response defaults to the oldest version of the API, meaning users that don't bother passing in a v param are missing out on some modern features, but more importantly, the API will soon stop supporting API requests that don't pass a v param.

If you're rather discuss this off of GitHub issues, feel free to reach out to api@foursquare.com. We're making this change in the future and wanted to give adequate time for library owners to transition.

[baztokyo]

I see. Which value is appropriate if a v param is missing? Current date?

[octopi]

20131023 is certainly a possibility, but it shouldn't be dynamically be set to always be the "current" date (e.g., if a breaking JSON change happens tomorrow and your library always has the current date set, you could run into parse errors). Pick a date (strongly recommend after 20120609) as the minimum supported version of your library and stick to that as the default, allowing your users to override if they wish.

[baztokyo]

We've released 1.1.6. "20120609" as the default value has been added. Please confirm the change.

[octopi]

LGTM, so long as the library still pass your tests.

I would still strongly recommend at some point moving to a more modern version though. You could be missing out on some newer features of the API. (For example, compare a venues/explore request with 20120609 vs 20131024. The new "snippets" justification block was added since last June!)

[mikegottlieb]

I think you need 20120610 at least. I was getting request failures with a response from Foursquare saying that 20120609 is no longer supported.

    $ Error getting foursquare checkins: Error Domain=BZFoursquareErrorDomain Code=410 "The operation couldn’t be completed. (BZFoursquareErrorDomain error 410.)" UserInfo=0x16d2f580 {errorDetail=The Foursquare API no longer supports requests that pass in a version v <= 20120609. For more details see https://developer.foursquare.com/overview/versioning, code=410, errorType=param_error}

[octopi]

As noted last year, the recommendation was to make the date after 20120609, which we have since deprecated.

[mikegottlieb]

Right, but the default in this library is still this: https://github.com/baztokyo/foursquare-ios-api/blob/master/BZFoursquare/BZFoursquare.m#L37 So shouldn't this be updated to at least 20120610?