On Thu, Feb 12, 2009 at 10:05 AM, Rolsch <[email protected]> wrote: > > On 5 Feb., 22:58, Trevor Johns <[email protected]> wrote: >> Version 2.0 will remain available to clients that wish to retain the API's >> previous behavior. >> >> - An HTTP410(Gone) status message is now returned if the `updated-min` >> query parameter for a request is too far in the past. > > Hello > > It seems there is a bug! > With the GET Http-Header "GData-Version: 2" set, it will answer with > the (wrong) headers: > > Vary: Accept, GData-Version > GData-Version: 2.1 > > So version 2.0 is affected, too... the behavior of "updated-min" > changed in my tool iCal4OL. > I don't know, if "?v=2" is working - but the header method is > definitely not working correctly! > > Regards > Roland
Hi Roland, Sorry about the confusion here, we're still working out some of the details on our end on how minor versioning works (to my knowledge, the Calendar API is the first service to use this), so most of the public documentation on this topic isn't available yet. Here's a summary, as things currently stand: If you request a major version without specifying a minor version (in other words, you request Gdata-Version: 2), you will get the latest version of the API, whatever that happens to be. At the moment, this would be v2.1. If you request a specific minor version, we will parse your request using the logic for that minor version, but will return a response using the latest minor version available for the corresponding major version. So, to give an example, let's say we have 4 versions of the API: v1.0 v2.0 v2.1 v3 (doesn't really exist, at least not yet) If you request v2.0 (in other words, you send Gdata-Version: 2.0), we will use the v2.0 logic to parse your request. However, you will get a v2.1 response back, since that's the latest version available in the 2.X series. In theory, the difference in the output between minor versions should be trivial. If a change is drastic enough to break backwards compatibility, the current plan is to increase the major version number. For now, you can think of the Gdata-Version header as follows: Gdata-Version: 1 => Equivalent to v1.0 Gdata-Version: 1.0 => Uses old namespaces, no support for ETags, updated-min can take invalid values, doesn't always catch gCal:eid conflicts. Response will be marked as v1.0. Gdata-Version: 2 => Equivalent to v2.1 (for now) Gdata-Version: 2.0 => Uses new namespaces, supports ETags, updated-min can take invalid values, doesn't always catch gCal:eid conflicts. Response will be marked as v2.1. Gdata-Version: 2.1 => Uses new namespaces, supports ETags, updated-min values constrained to available dataset, more picky about catching gCal:eid conflicts. Response will be marked as v2.1. Again, we haven't published any documentation on this behavior, so there is a chance that all of this might still change. I recommend keeping an eye on this list and subscribe the changelog Atom feed (http://code.google.com/apis/calendar/changelog.xml), to stay on top of any changes as they're announced. -- Trevor Johns --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Calendar Data API" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/google-calendar-help-dataapi?hl=en -~----------~----~----~----~------~----~------~--~---
