MobilityData
Predictable Release Cycles
Problem
It's difficult for GBFS users to predict when a Release Candidate version will become an Official version.
Indeed, a Release Candidate version becomes Official when the Maintainer considers that the changes implemented by First Adopters are sufficient to constitute a new version.
From the governance (thanks @mplsmitch for pointing it out):
Changes that have not met the implementation requirements MAY be removed from a Release Candidate so that successfully implemented parts of the Release Candidate can become an official release.
Proposed solution
We propose to edit the governance.md to keep the same Release Cycles but to remove the concept of Release Candidate. Any change voted on and implemented by First Adopters would become Official during the next planned version release (May or November).
Before:
- The changes that have been voted on are batched into a Release Candidate version.
- A Release Candidate version can be released no more than every 6 months for non-breaking changes and no more than every 12 months for breaking changes.
- The Release Candidate version becomes Official when the Maintainer considers that the changes implemented by First Adopters are sufficient to constitute a new version (which is difficult to predict when this will be for GBFS users).
After (proposal):
- The changes that have been voted are immediately available for implementation by First Adopters.
- A new Official version is released every 6 months for non-breaking changes and every 12 months for breaking changes, with only the changes implemented by First Adopters.
- Changes that were not implemented by First Adopters are delayed to the next version.
Benefits
GBFS users can know exactly when a new version will be available. The principle of voting and implementation by First Adopters is preserved. The release cadence of new versions is also preserved.
Limitations
The exact content of a new release is not guaranteed. It will depend on the First Adopters. In my opinion this is not a problem, but I am open to being proven otherwise.
The case of v3 (subject to a vote in other issue)
v3.0-RC was released on March 10, 2023 and v3.0-RC2 was released on November 14, 2023 (because v3.0-RC was still not Official).
If this new Release Cycle is adopted, v3 would become Official, with the changes implemented by First Adopters, in November 2024 because it’s a MAJOR version.
We propose to open a vote in a separate issue to exceptionally make v3 Official in May instead of November to make v3 changes available sooner.
I understand the frustration with how long it's taking for implementation of v3.0. Here are some things I want to point out:
Last fall we made changes to the governance, setting deadlines for adding new PRs to release candidates. Prior to this you could call a vote at any time and those features would be added to the RC. One of the issues with v3 was that more features were added after v3.0-RC, which lead to v3.0-RC2, further delaying complete implementation. This should be less of a problem going forward because we've limited release candidates to a maximum of two per year.
It's also important to note that the two releases candidates per year are the maximum allowed, not a requirement. There could always be less than two and probably should be. I think this is a particularly important point because if new versions are released too frequently, we will create tech debt for producers who will not update to the latest version. The specification is 10 years old and we're just now getting to v3, meanwhile we have some producers who are still on v1.x. Planning for a MAJOR version every November seems like a terrible idea to me. The goal should be to get everyone publishing the same version, and we have to balance that against the need for new features.
We propose to open a vote in a separate issue to exceptionally make v3 Official in May instead of November to make v3 changes available sooner.
Up to this point this isn't how things have worked. May and November are only relevant in the case of release candidates. A version can be made official at any time, as soon as the implementation requirements have been met, for example if all requirements were met by June 5th, v3.0 would be official June 5th. There's no reason to wait until November. As I understand your diagram above, if a version was fully implemented at any time between May and November, it wouldn't become official until November. I don't think that makes sense.
We also have a lot of flexibility in the current governance to to remove features that are delaying an official release. If there's no interest in implementing a new feature, we can pull it out and make the rest of the release official. I think that's certainly going to be necessary with #457.
From the governance:
Changes that have not met the implementation requirements MAY be removed from a Release Candidate so that successfully implemented parts of the Release Candidate can become an official release. Any changes that are removed MAY become part of a future Release Candidate.
From the governance:
Changes that have not met the implementation requirements MAY be removed from a Release Candidate so that successfully implemented parts of the Release Candidate can become an official release. Any changes that are removed MAY become part of a future Release Candidate.
Thank you for the reminder of this rule, I was not familiar with it! (I updated the issue description)
It may indeed be necessary to remove #457, and perhaps also #546, from v3.0-RC.
This may be enough to resolve the issue of how long it takes for a release to become official. We could then keep the current Release Candidate system.
What do other people think?
I appreciate the effort to accelerate the release schedule. Preventing the release of official versions just because some feature isn't implemented by anyone doesn't make sense indeed. I also see a bit of a chicken & egg problem. As long as a version isn't officially released, many providers (and to a lesser degree consumers) will hesitate jumping on it. So I question the requirement of having both a producer and a consumer who implement the change. The changes were all voted upon in the governance process, so why do we need another step to release them?
I agree with @futuretap. Why is the extra step of implementation needed for a change to be official? It's indeed a chicken & egg problem. Is there a similar process in GTFS? Imho if the community accepts a proposal by vote, there's no reason not to make that unconditionally official in the next release.
GTFS has the same requirement, that's how it became part of GBFS. In the GTFS process both a consumer and a producer must implement but that has to happen before the proposal is voted on. GTFS doesn't have versioning so they don't have this issue. There's been some discussion in the past about adding versioning and changing their process to something closer to GBFS. The reason for this in both GTFS and GBFS was to make it harder to add speculative features to the specifications that would never be implemented & consumed. That's mostly worked, although I do think there are fields in GBFS now that may never be used.
Obviously I wrote the comment without thinking much about the history. I understand there is a context - I just intuitively and spontaneously found it odd.
That's mostly worked, although I do think there are fields in GBFS now that may never be used.
So there are features of GBFS that were voted upon and passed, but never implemented? Or have they just become obsolete, and not being used anymore?
So there are features of GBFS that were voted upon and passed, but never implemented? Or have they just become obsolete, and not being used anymore?
As far as I know it's all been implemented but there are optional fields, particularly in vehicle_types.json that I don't expect to see displayed in an app any time soon.
This discussion has been automatically marked as stale because it has not had recent activity. It will be closed in 30 days if no further activity occurs. Thank you for your contributions.
This discussion has been closed due to inactivity. Discussions can always be reopened after they have been closed.