[Discussion] GTFS Realtime Versioning

[tzujenchanmbd]

In recent discussions regarding Realtime spec, the community seems to have encountered difficulties in reaching consensus, leading to the topic of versioning being raised in the recent PR#504.

To address this, we are opening this issue dedicated to discussing GTFS Realtime versioning.

The following questions may help us begin to think about this significant topic:

• If we implement versioning (i.e., a mechanism for incrementing version numbers), should this mechanism allow for breaking changes for producers by permitting new versions to be incompatible with older versions? For example, should it allow for the complete removal of certain elements or the redefinition (modification) of content from previous versions in the new version spec?
• Compared to the existing mechanism of using the [deprecated = true] tag, what are the advantages and potential risks of implementing versioning?

[skinkie]

I think removing elements is not what we want, because that would make the protobuf file unparsible by a newer version by default. The more complex situation is if the structure would change in a higher version, effectively not being backwards compatible by the wire-protocol. In #504 the difficulty is an interpretation change, or better put, any interpretation, being this one. Such "clarification-change" might break existing implementations, were the standard has diverted because of the lack of clarity or an actor being unconsciously incompetent.

Now what if we would break private extensions? If private extensions were never put here on the table, breaking something that would break the private extension: is not our problem. There are parties that have implemented feature X**'**, misreading it for feature X. To help in such transition, and to be able to make a distinction we could bump a version. This is different from [deprecated=True] because the deprecated status suggests the feature is not available anymore, while in this case the feature is merely wrongfully implemented by a group of users.

In high sight what was the reason for bumping to version 2.0? Can we learn anything from that?

I would also suggest a clear development path that would basically state which issues or features we want to resolve in a certain time frame, so it is clear that if there are "breaking changes" the timeline is clear to aggregate all changes for a new version.