mplsmitch
commented
3 years ago Hi @evansiroky,
Great question. We've been discussing this internally because although the README states:
GBFS documentation will include a designated long-term support (LTS) branch.
there is no LTS branch identified in the documentation. The README also states:
The LTS branch will be determined according to the GBFS voting process.
A vote to designate a LTS branch has never taken place. There has never been a designated LTS branch so there's no past timeline of LTS branch status. We've been planning to schedule a vote sometime later this year. My expectation is that we would be voting on v2.2 or upcoming version v2.3 that will come out of the current votes. v2.3 will be in release candidate status for some time until it's been fully implemented so it seems like if we want to hold a vote soon we should be looking at v2.2.
Since this has never been done before, this is a good time to figure out if there are changes to the process or clarifications needed.
One area that is kind of messy has to do with the release dates and the GitHub tag metadata that you mentioned. This actually is true of all tagged releases. The reason for the discrepancy between the dates in release notes and the GitHub tag is that often minor mistakes are found after a release that need to be corrected. That means deleting the vX.X tag, making the corrections and then recreating the tag. Each time this happens the date in the tag metadata changes. I've been putting the actual release date in both the version history on the README and in the release tag notes but I agree it's confusing.
Also, In the README it says:
Non-breaking changes (MINOR) will be applied to the LTS branch when relevant.
I don't know what "when relevant" means but if we designate an LTS branch and then apply future non-breaking changes, the date in the tag for the release will never make sense. The other part I'm puzzled by is that if we were to designate v2.2 as the LTS branch and then apply all the v2.3 changes to it then v2.2 effectively becomes v2.3, or any future MINOR version <v3.0.
Anecdotally what I've seen when producers have updated feeds from v1.x to 2.x has been mixed. Some have continued to publish the v1.x feeds and some have not.
I would love to hear everyone's thoughts on both the long-tern support issue and the release process in general.
josee-sabourin
What is the issue and why is it an issue?
In the README there is a mention of a “long-term support” branch that states:
It seems like there is a “current release” noted in the README. Also, it doesn’t seem like there is a noted start date for when 2.2 became the current release other than its GitHub tag metadata. Does the current release always equal the LTS branch?
Also, it would be nice to know the past timeline of which current release/LTS branch had "LTS branch" status in the past. For example, I can see a GitHub tag about v1.0 which was produced on Dec 10, 2019 - although the release notes say it is as of October 2019. Does this mean that v1.0 is still in LTS status since it hasn't been 2 years? And does this also mean consumers should expect producers to keep publishing these v1.0 feeds until this October after which the producers could immediately turn off those v1.0 endpoints in favor of v1.1 until March 16, 2022?
Please describe some potential solutions you have considered (even if they aren’t related to GBFS).
It would be great to have some notes in the README that spell out the exact timeline that should be expected for producers to maintain API endpoints that support older releases so that consumers know when they need to make their software compatible with future GBFS versions.
Is your potential solution a breaking change?