From 29db8094b27fcb523042801b3d7d70e3f7981931 Mon Sep 17 00:00:00 2001 From: Aaron Antrim Date: Wed, 6 Nov 2019 10:35:35 -0800 Subject: [PATCH 1/7] Spec versioning proposal First draft proposal --- README.md | 20 ++++++++++++++++++ gbfs.md | 62 +++++++++++++++++++++++++++++++++++++++++++++++++++---- 2 files changed, 78 insertions(+), 4 deletions(-) diff --git a/README.md b/README.md index bb7cd8f8..aaf0e5ca 100644 --- a/README.md +++ b/README.md @@ -40,6 +40,26 @@ The general outline for changing the spec has 4 steps: 3. Find at least one GBFS producer to implement and test the proposed change. 4. Submit a final request-for-comments on the proposed change to the issue discussion. If no outstanding issues are identified after one week’s time, and there is general agreement that the proposed change is worthwhile and follows the GBFS guiding principles outlined below, the proposal will be officially adopted. +## Specification versioning +To enable the evolution of GBFS, including changes that would otherwise break backwards-compatibility with consuming applications, GBFS documentation is versioned. A git tag in the form of `X.Y` establishes semantic versions. Git tags batch pull requests into versions. + +A whole integer increase is used for breaking changes (MAJOR changes). A decimal increase is used for non-breaking changes (MINOR changes or patches). + +Examples of breaking changes include: + +* Adding or removing a required endpoint or field +* Changing the data type or semantics of an existing field + +Examples of non-breaking changes include: + +* Adding or removing an optional endpoint or field +* Adding or removing enum values +* Modifying documentation or spec language in a way that clarifies semantics or recommended practices + +### Version release cycles +* There is no strict limitation on the frequency of MAJOR releases, but the GBFS community aims to limit the MAJOR releases to 2 or less every 12 months. To limit releases, breaking changes can be batched together. +* MINOR changes may be applied at any time. There is no guideline to limit the number of MINOR changes. +* GBFS documentation will include a designated long-term support (LTS) branch. The LTS branch must maintain backwards compatibility for a period of 2 years. Non-breaking changes (MINOR) may be applied to the LTS branch. ## Extensions Outside of the Specification ## To accommodate the needs of feed producers and consumers prior to the adoption of a change, additional fields can be added to feeds even if these fields are not part of the official specification. It's strongly recommended that these additional fields be documented on the wiki page in this format: diff --git a/gbfs.md b/gbfs.md index 65336087..f46ea8b9 100644 --- a/gbfs.md +++ b/gbfs.md @@ -34,12 +34,23 @@ This specification has been designed with the following concepts in mind: Historical data, including station details and ride data is to be provided by a more compact specification designed specifically for such archival purposes. The data in the specification contained in this document is intended for consumption by clients intending to provide real-time (or semi-real-time) transit advice and is designed as such. +## Versioning +The version of the GBFS documentation in which a feed is encoded is declared in all file headers. See [Output Format][#Output Format]. GBFS + +GBFS Best Practice defines that: +* *GBFS producers* should provide an endpoint that conforms to the current long term support (LTS) branch and the latest release branch (within 3 months of release). See [specification versioning](README.md#Specification_Versioning) +* *GBFS consumers* should, at a minumum, consume the current LTS branch. It highly recommended that GBFS consumers support later releases. + +Default GBFS feed URLs, e.g. `https://www.example.com/data/gbfs.json` or `https://www.example.com/data/fr/system_information.json` should direct consumers to the feed encoded according to the current LTS documentation branch. + + ## Files This specification defines the following files along with their associated content: File Name | Required | Defines --------------------------- | ----------------------- | ---------- gbfs.json | Optional | Auto-discovery file that links to all of the other files published by the system. This file is optional, but highly recommended. +gbfs_versions.json | Optional | Lists all feed endpoints published according to versions of the GBFS documentation. system_information.json | Yes | Describes the system including System operator, System location, year implemented, URLs, contact info, time zone station_information.json | Conditionally required | Mostly static list of all stations, their capacities and locations. Required of systems utilizing docks. station_status.json | Conditionally required | Number of available bikes and docks at each station and station availability. Required of systems utilizing docks. @@ -96,13 +107,16 @@ Field Name | Required | Defines --------------------| ----------| ---------- last_updated | Yes | Integer POSIX timestamp indicating the last time the data in this feed was updated ttl | Yes | Integer representing the number of seconds before the data in this feed will be updated again (0 if the data should always be refreshed) +version | Yes | GBFS version number in which feed data is encoded, according to the versioning framework. data | Yes | JSON hash containing the data fields for this response + Example: ```json { "last_updated": 1434054678, "ttl": 3600, + "version":"1.0", "data": { "name": "Citi Bike", "system_id": "citibike_com" @@ -115,27 +129,31 @@ The following fields are all attributes within the main "data" object for this f Field Name | Required | Defines ------------------------| ------------| ---------- +stations | Yes | Array that contains one object per station in the system as defined below + _language_ | Yes | The language that all of the contained files will be published in. This language must match the value in the system_information file \- feeds | Yes | An array of all of the feeds that are published by this auto-discovery file \- name | Yes | Key identifying the type of feed this is (e.g. "system_information", "station_information") \- url | Yes | Full URL for the feed + Example: ```json { "last_updated": 1434054678, "ttl": 0, + "version":"1.0", "data": { "en": { "feeds": [ { "name": "system_information", - "url": "https://www.example.com/gbfs/en/system_information" + "url": "https://www.example.com/gbfs/1.0/en/system_information" }, { "name": "station_information", - "url": "https://www.example.com/gbfs/en/station_information" + "url": "https://www.example.com/gbfs/1.0/en/station_information" } ] }, @@ -143,11 +161,11 @@ Example: "feeds": [ { "name": "system_information", - "url": "https://www.example.com/gbfs/fr/system_information" + "url": "https://www.example.com/gbfs/1.0/fr/system_information" }, { "name": "station_information", - "url": "https://www.example.com/gbfs/fr/station_information" + "url": "https://www.example.com/gbfs/1.0/fr/station_information" } ] } @@ -155,6 +173,41 @@ Example: } ``` +### gbfs_versions.json +Each expression of a GBFS feed describes all of the versions that are available. + +The following fields are all attributes within the main "data" object for this feed. + +Field Name | Required | Defines +------------------------| ------------| ---------- +_versions_ | Yes | Array that contains one object, as defined below, for each of the available versions of a feed. + \- version | Yes | String identifying the semantic version of the feed in the form X.Y. + \- url | Yes | URL of the corresponding gbfs.json endpoint. + +```json +{ + "last_updated": 1434054678, + "ttl": 0, + "version":"1.0", + "data": { + [ + { + "version":"1.0", + "url":"https://www.example.com/gbfs/1.0/gbfs" + }, + { + "version":"1.1", + "url":"https://www.example.com/gbfs/1.1/gbfs" + }, + { + "version":"2.0", + "url":"https://www.example.com/gbfs/2.0/gbfs" + } + ] + } +} +``` + ### system_information.json The following fields are all attributes within the main "data" object for this feed. @@ -235,6 +288,7 @@ Example: { "last_updated": 1434054678, "ttl": 0, + "version":"1.0", "data": { "rental_hours": [ { From ea50d811bccb26b11ee836258d34af0609a44339 Mon Sep 17 00:00:00 2001 From: Aaron Antrim Date: Wed, 6 Nov 2019 10:46:04 -0800 Subject: [PATCH 2/7] Corrections to initial commit --- README.md | 4 ++-- gbfs.md | 6 +++--- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/README.md b/README.md index aaf0e5ca..05fd6d6b 100644 --- a/README.md +++ b/README.md @@ -40,7 +40,7 @@ The general outline for changing the spec has 4 steps: 3. Find at least one GBFS producer to implement and test the proposed change. 4. Submit a final request-for-comments on the proposed change to the issue discussion. If no outstanding issues are identified after one week’s time, and there is general agreement that the proposed change is worthwhile and follows the GBFS guiding principles outlined below, the proposal will be officially adopted. -## Specification versioning +## Specification Versioning To enable the evolution of GBFS, including changes that would otherwise break backwards-compatibility with consuming applications, GBFS documentation is versioned. A git tag in the form of `X.Y` establishes semantic versions. Git tags batch pull requests into versions. A whole integer increase is used for breaking changes (MAJOR changes). A decimal increase is used for non-breaking changes (MINOR changes or patches). @@ -56,7 +56,7 @@ Examples of non-breaking changes include: * Adding or removing enum values * Modifying documentation or spec language in a way that clarifies semantics or recommended practices -### Version release cycles +### Version Release Cycles * There is no strict limitation on the frequency of MAJOR releases, but the GBFS community aims to limit the MAJOR releases to 2 or less every 12 months. To limit releases, breaking changes can be batched together. * MINOR changes may be applied at any time. There is no guideline to limit the number of MINOR changes. * GBFS documentation will include a designated long-term support (LTS) branch. The LTS branch must maintain backwards compatibility for a period of 2 years. Non-breaking changes (MINOR) may be applied to the LTS branch. diff --git a/gbfs.md b/gbfs.md index f46ea8b9..ef828f74 100644 --- a/gbfs.md +++ b/gbfs.md @@ -35,11 +35,11 @@ This specification has been designed with the following concepts in mind: Historical data, including station details and ride data is to be provided by a more compact specification designed specifically for such archival purposes. The data in the specification contained in this document is intended for consumption by clients intending to provide real-time (or semi-real-time) transit advice and is designed as such. ## Versioning -The version of the GBFS documentation in which a feed is encoded is declared in all file headers. See [Output Format][#Output Format]. GBFS +The version of the GBFS documentation in which a feed is encoded is declared in all file headers. See [Output Format](#output-format). GBFS Best Practice defines that: -* *GBFS producers* should provide an endpoint that conforms to the current long term support (LTS) branch and the latest release branch (within 3 months of release). See [specification versioning](README.md#Specification_Versioning) -* *GBFS consumers* should, at a minumum, consume the current LTS branch. It highly recommended that GBFS consumers support later releases. +* _GBFS producers_ should provide an endpoint that conforms to the current long term support (LTS) branch and the latest release branch (within 3 months of release). See [specification versioning](README.md#specification-versioning) +* _GBFS consumers_ should, at a minumum, consume the current LTS branch. It highly recommended that GBFS consumers support later releases. Default GBFS feed URLs, e.g. `https://www.example.com/data/gbfs.json` or `https://www.example.com/data/fr/system_information.json` should direct consumers to the feed encoded according to the current LTS documentation branch. From 8cf699e870b593e878d9de63ace268c764312d40 Mon Sep 17 00:00:00 2001 From: Aaron Antrim Date: Thu, 7 Nov 2019 09:10:44 -0800 Subject: [PATCH 3/7] Improvements & clarifications In response to review by @barbeau --- README.md | 8 ++++---- gbfs.md | 18 +++++++++--------- 2 files changed, 13 insertions(+), 13 deletions(-) diff --git a/README.md b/README.md index 05fd6d6b..f3895f01 100644 --- a/README.md +++ b/README.md @@ -41,7 +41,7 @@ The general outline for changing the spec has 4 steps: 4. Submit a final request-for-comments on the proposed change to the issue discussion. If no outstanding issues are identified after one week’s time, and there is general agreement that the proposed change is worthwhile and follows the GBFS guiding principles outlined below, the proposal will be officially adopted. ## Specification Versioning -To enable the evolution of GBFS, including changes that would otherwise break backwards-compatibility with consuming applications, GBFS documentation is versioned. A git tag in the form of `X.Y` establishes semantic versions. Git tags batch pull requests into versions. +To enable the evolution of GBFS, including changes that would otherwise break backwards-compatibility with consuming applications, GBFS documentation is versioned. A git tag in the form of `X.Y` establishes semantic versions. Multiple changes (commits) may be batched into a single new release. A whole integer increase is used for breaking changes (MAJOR changes). A decimal increase is used for non-breaking changes (MINOR changes or patches). @@ -57,9 +57,9 @@ Examples of non-breaking changes include: * Modifying documentation or spec language in a way that clarifies semantics or recommended practices ### Version Release Cycles -* There is no strict limitation on the frequency of MAJOR releases, but the GBFS community aims to limit the MAJOR releases to 2 or less every 12 months. To limit releases, breaking changes can be batched together. -* MINOR changes may be applied at any time. There is no guideline to limit the number of MINOR changes. -* GBFS documentation will include a designated long-term support (LTS) branch. The LTS branch must maintain backwards compatibility for a period of 2 years. Non-breaking changes (MINOR) may be applied to the LTS branch. +* There is no strict limitation on the frequency of MAJOR releases, but the GBFS community aims to limit the MAJOR releases to 2 or fewer every 12 months. To limit releases, breaking changes can be batched together. +* MINOR changes may be applied at any time. There is no guideline to limit the number of MINOR changes. MINOR changes may be batched or released immediately, at the discretion of the pull request author and advocate. +* GBFS documentation will include a designated long-term support (LTS) branch. The LTS branch would maintain its LTS status for at least 2 years, after which a new LTS release and branch would be designated. The LTS branch will be determined according to the GBFS voting process. Non-breaking changes (MINOR) will be applied to the LTS branch when relevant. ## Extensions Outside of the Specification ## To accommodate the needs of feed producers and consumers prior to the adoption of a change, additional fields can be added to feeds even if these fields are not part of the official specification. It's strongly recommended that these additional fields be documented on the wiki page in this format: diff --git a/gbfs.md b/gbfs.md index ef828f74..f68482d2 100644 --- a/gbfs.md +++ b/gbfs.md @@ -35,13 +35,15 @@ This specification has been designed with the following concepts in mind: Historical data, including station details and ride data is to be provided by a more compact specification designed specifically for such archival purposes. The data in the specification contained in this document is intended for consumption by clients intending to provide real-time (or semi-real-time) transit advice and is designed as such. ## Versioning -The version of the GBFS documentation in which a feed is encoded is declared in all file headers. See [Output Format](#output-format). +The version of the GBFS specification to which a feed conforms is declared in the `version` field in all files. See [Output Format](#output-format). GBFS Best Practice defines that: -* _GBFS producers_ should provide an endpoint that conforms to the current long term support (LTS) branch and the latest release branch (within 3 months of release). See [specification versioning](README.md#specification-versioning) -* _GBFS consumers_ should, at a minumum, consume the current LTS branch. It highly recommended that GBFS consumers support later releases. -Default GBFS feed URLs, e.g. `https://www.example.com/data/gbfs.json` or `https://www.example.com/data/fr/system_information.json` should direct consumers to the feed encoded according to the current LTS documentation branch. +_GBFS producers_ should provide endpoints that conform to both the current specification long term support (LTS) branch as well as the latest release branch within at least 3 months of a new spec `MAJOR` or `MINOR` version release. See [specification versioning](README.md#specification-versioning) + +_GBFS consumers_ should, at a minumum, support the current LTS branch. It highly recommended that GBFS consumers support later releases. + +Default GBFS feed URLs, e.g. `https://www.example.com/data/gbfs.json` or `https://www.example.com/data/fr/system_information.json` must direct consumers to the feed that conforms to the current LTS documentation branch. ## Files @@ -50,7 +52,7 @@ This specification defines the following files along with their associated conte File Name | Required | Defines --------------------------- | ----------------------- | ---------- gbfs.json | Optional | Auto-discovery file that links to all of the other files published by the system. This file is optional, but highly recommended. -gbfs_versions.json | Optional | Lists all feed endpoints published according to versions of the GBFS documentation. +gbfs_versions.json | Optional | Lists all feed endpoints published according to versions of the GBFS documentation. system_information.json | Yes | Describes the system including System operator, System location, year implemented, URLs, contact info, time zone station_information.json | Conditionally required | Mostly static list of all stations, their capacities and locations. Required of systems utilizing docks. station_status.json | Conditionally required | Number of available bikes and docks at each station and station availability. Required of systems utilizing docks. @@ -107,7 +109,7 @@ Field Name | Required | Defines --------------------| ----------| ---------- last_updated | Yes | Integer POSIX timestamp indicating the last time the data in this feed was updated ttl | Yes | Integer representing the number of seconds before the data in this feed will be updated again (0 if the data should always be refreshed) -version | Yes | GBFS version number in which feed data is encoded, according to the versioning framework. +version | Yes | String - GBFS version number to which the feed confirms, according to the versioning framework. data | Yes | JSON hash containing the data fields for this response @@ -129,8 +131,6 @@ The following fields are all attributes within the main "data" object for this f Field Name | Required | Defines ------------------------| ------------| ---------- -stations | Yes | Array that contains one object per station in the system as defined below - _language_ | Yes | The language that all of the contained files will be published in. This language must match the value in the system_information file \- feeds | Yes | An array of all of the feeds that are published by this auto-discovery file \- name | Yes | Key identifying the type of feed this is (e.g. "system_information", "station_information") @@ -180,7 +180,7 @@ The following fields are all attributes within the main "data" object for this f Field Name | Required | Defines ------------------------| ------------| ---------- -_versions_ | Yes | Array that contains one object, as defined below, for each of the available versions of a feed. +_versions_ | Yes | Array that contains one object, as defined below, for each of the available versions of a feed. The array must be sorted by increasing MAJOR and MINOR version number. \- version | Yes | String identifying the semantic version of the feed in the form X.Y. \- url | Yes | URL of the corresponding gbfs.json endpoint. From d746a64b6f4939d62e0958f3989ec10c2e39e22d Mon Sep 17 00:00:00 2001 From: Aaron Antrim Date: Thu, 7 Nov 2019 14:57:56 -0800 Subject: [PATCH 4/7] corrections responding to comments from @jcn --- README.md | 2 +- gbfs.md | 37 +++++++++++++++++++------------------ 2 files changed, 20 insertions(+), 19 deletions(-) diff --git a/README.md b/README.md index f3895f01..ad7e62b0 100644 --- a/README.md +++ b/README.md @@ -41,7 +41,7 @@ The general outline for changing the spec has 4 steps: 4. Submit a final request-for-comments on the proposed change to the issue discussion. If no outstanding issues are identified after one week’s time, and there is general agreement that the proposed change is worthwhile and follows the GBFS guiding principles outlined below, the proposal will be officially adopted. ## Specification Versioning -To enable the evolution of GBFS, including changes that would otherwise break backwards-compatibility with consuming applications, GBFS documentation is versioned. A git tag in the form of `X.Y` establishes semantic versions. Multiple changes (commits) may be batched into a single new release. +To enable the evolution of GBFS, including changes that would otherwise break backwards-compatibility with consuming applications, GBFS documentation is versioned. Semantic versions are established by a git tag in the form of `vX.Y` where `X.Y` is the version name. Multiple changes (commits) may be batched into a single new release. A whole integer increase is used for breaking changes (MAJOR changes). A decimal increase is used for non-breaking changes (MINOR changes or patches). diff --git a/gbfs.md b/gbfs.md index f68482d2..16e87780 100644 --- a/gbfs.md +++ b/gbfs.md @@ -118,7 +118,7 @@ Example: { "last_updated": 1434054678, "ttl": 3600, - "version":"1.0", + "version": "1.0", "data": { "name": "Citi Bike", "system_id": "citibike_com" @@ -143,7 +143,7 @@ Example: { "last_updated": 1434054678, "ttl": 0, - "version":"1.0", + "version": "1.0", "data": { "en": { "feeds": [ @@ -188,22 +188,23 @@ _versions_ | Yes | Array that contains one object, as defin { "last_updated": 1434054678, "ttl": 0, - "version":"1.0", + "version": "1.0", "data": { - [ - { - "version":"1.0", - "url":"https://www.example.com/gbfs/1.0/gbfs" - }, - { - "version":"1.1", - "url":"https://www.example.com/gbfs/1.1/gbfs" - }, - { - "version":"2.0", - "url":"https://www.example.com/gbfs/2.0/gbfs" - } - ] + "versions": + [ + { + "version": "1.0", + "url":"https://www.example.com/gbfs/1.0/gbfs" + }, + { + "version":"1.1", + "url":"https://www.example.com/gbfs/1.1/gbfs" + }, + { + "version":"2.0", + "url":"https://www.example.com/gbfs/2.0/gbfs" + } + ] } } ``` @@ -288,7 +289,7 @@ Example: { "last_updated": 1434054678, "ttl": 0, - "version":"1.0", + "version": "1.0", "data": { "rental_hours": [ { From 1397ac436130474912adfbdf02f701e93e84368c Mon Sep 17 00:00:00 2001 From: Aaron Antrim Date: Mon, 11 Nov 2019 18:10:54 -0800 Subject: [PATCH 5/7] new examples, URL scheme In response to @jcn's comment https://github.com/NABSA/gbfs/pull/188#discussion_r343797702 --- gbfs.md | 30 +++++++++++++----------------- 1 file changed, 13 insertions(+), 17 deletions(-) diff --git a/gbfs.md b/gbfs.md index 16e87780..dfa54015 100644 --- a/gbfs.md +++ b/gbfs.md @@ -39,7 +39,7 @@ The version of the GBFS specification to which a feed conforms is declared in th GBFS Best Practice defines that: -_GBFS producers_ should provide endpoints that conform to both the current specification long term support (LTS) branch as well as the latest release branch within at least 3 months of a new spec `MAJOR` or `MINOR` version release. See [specification versioning](README.md#specification-versioning) +_GBFS producers_ should provide endpoints that conform to both the current specification long term support (LTS) branch as well as the latest release branch within at least 3 months of a new spec `MAJOR` or `MINOR` version release. It is not necessary to support more than one `MINOR` release of the same `MAJOR` release group because `MINOR` releases are backwards-compatible. See [specification versioning](README.md#specification-versioning) _GBFS consumers_ should, at a minumum, support the current LTS branch. It highly recommended that GBFS consumers support later releases. @@ -118,7 +118,7 @@ Example: { "last_updated": 1434054678, "ttl": 3600, - "version": "1.0", + "version": "2.1", "data": { "name": "Citi Bike", "system_id": "citibike_com" @@ -143,17 +143,17 @@ Example: { "last_updated": 1434054678, "ttl": 0, - "version": "1.0", + "version": "2.1", "data": { "en": { "feeds": [ { "name": "system_information", - "url": "https://www.example.com/gbfs/1.0/en/system_information" + "url": "https://www.example.com/gbfs/2/en/system_information" }, { "name": "station_information", - "url": "https://www.example.com/gbfs/1.0/en/station_information" + "url": "https://www.example.com/gbfs/2/en/station_information" } ] }, @@ -161,11 +161,11 @@ Example: "feeds": [ { "name": "system_information", - "url": "https://www.example.com/gbfs/1.0/fr/system_information" + "url": "https://www.example.com/gbfs/2/fr/system_information" }, { "name": "station_information", - "url": "https://www.example.com/gbfs/1.0/fr/station_information" + "url": "https://www.example.com/gbfs/2/fr/station_information" } ] } @@ -188,21 +188,17 @@ _versions_ | Yes | Array that contains one object, as defin { "last_updated": 1434054678, "ttl": 0, - "version": "1.0", + "version": "2.1", "data": { "versions": [ { - "version": "1.0", - "url":"https://www.example.com/gbfs/1.0/gbfs" + "version":"1", + "url":"https://www.example.com/gbfs/1/gbfs" }, { - "version":"1.1", - "url":"https://www.example.com/gbfs/1.1/gbfs" - }, - { - "version":"2.0", - "url":"https://www.example.com/gbfs/2.0/gbfs" + "version":"2", + "url":"https://www.example.com/gbfs/2/gbfs" } ] } @@ -289,7 +285,7 @@ Example: { "last_updated": 1434054678, "ttl": 0, - "version": "1.0", + "version": "2.1", "data": { "rental_hours": [ { From fc77ed267d0a6199f1eccf5e9e14dc4e2cfe51a6 Mon Sep 17 00:00:00 2001 From: Aaron Antrim Date: Mon, 18 Nov 2019 10:58:50 -0800 Subject: [PATCH 6/7] minor clarification to examples "version": "2.1" -> "version": "1.0" as per @jcn suggestion Co-Authored-By: Jesse Chan-Norris --- gbfs.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/gbfs.md b/gbfs.md index dfa54015..639fcebd 100644 --- a/gbfs.md +++ b/gbfs.md @@ -118,7 +118,7 @@ Example: { "last_updated": 1434054678, "ttl": 3600, - "version": "2.1", + "version": "1.0", "data": { "name": "Citi Bike", "system_id": "citibike_com" @@ -143,7 +143,7 @@ Example: { "last_updated": 1434054678, "ttl": 0, - "version": "2.1", + "version": "1.0", "data": { "en": { "feeds": [ @@ -188,7 +188,7 @@ _versions_ | Yes | Array that contains one object, as defin { "last_updated": 1434054678, "ttl": 0, - "version": "2.1", + "version": "1.0", "data": { "versions": [ @@ -285,7 +285,7 @@ Example: { "last_updated": 1434054678, "ttl": 0, - "version": "2.1", + "version": "1.0", "data": { "rental_hours": [ { From c2dc3d63138b9eda55b9230547e67388c4260606 Mon Sep 17 00:00:00 2001 From: Aaron Antrim Date: Wed, 20 Nov 2019 16:29:10 -0800 Subject: [PATCH 7/7] Minor update to example data Change example data for gbfs.json to be consistent with a v1.0 example --- gbfs.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/gbfs.md b/gbfs.md index 639fcebd..4b05445c 100644 --- a/gbfs.md +++ b/gbfs.md @@ -149,11 +149,11 @@ Example: "feeds": [ { "name": "system_information", - "url": "https://www.example.com/gbfs/2/en/system_information" + "url": "https://www.example.com/gbfs/1/en/system_information" }, { "name": "station_information", - "url": "https://www.example.com/gbfs/2/en/station_information" + "url": "https://www.example.com/gbfs/1/en/station_information" } ] }, @@ -161,11 +161,11 @@ Example: "feeds": [ { "name": "system_information", - "url": "https://www.example.com/gbfs/2/fr/system_information" + "url": "https://www.example.com/gbfs/1/fr/system_information" }, { "name": "station_information", - "url": "https://www.example.com/gbfs/2/fr/station_information" + "url": "https://www.example.com/gbfs/1/fr/station_information" } ] }