With new fields being added to the spec, we wanted to revisit the concept of backwards compatibility in GTFS. Currently, CHANGES.md reads:

When adding features to the specification, we want to avoid making changes that will make existing feeds invalid. We don't want to create more work for existing feed publishers until they want to add capabilities to their feeds. Also, whenever possible, we want existing parsers to be able to continue to read the older parts of newer feeds.

As implied, there are 2 parties to consider: data producers and data consumers.

For data producers, backwards-compatibility means that any changes to the spec do not invalidate or change the meaning of old datasets. That is to say, data producers won't need to change their datasets to make room for a new feature. This is seems to have been respected so far, and is favorable to maintain for reasons mentioned above.

For data consumers, backwards-compatibility means that any changes to the spec will only be built "on top" of current code. Meaning that if a data consumer choses not to implement a new spec feature, all other historical implementations remain valid with old and new feeds containing the addition (the consumer will simply be ignoring the feature, with no consequence on other rider information).

The problem comes in when adding features that are non-backwards compatible for data consumers.

A recent example of this is the voting-in of #284. With the addition of more specific trip-to-trip and route-to-route transfers, consumers now have to update their code to look for trip-to-trip and route-to-route on top of the existing stop-to-stop transfers. If they don't, data consumers may be misrepresenting the specificity of transfers leading to errors in rider information.

More non-backwards compatible changes for data consumers are foreseeable. Otherwise, the development and improvement of GTFS would be severely limited.

Much of these issues stem from the fact that GTFS has no versioning (discussed previously in #215). While there is expressed interest from the community to version GTFS, there is also concern from other parties that this will complexify GTFS by encouraging breaking changes for all parties, leading to lower usage because of an additional barrier to entry/comprehension.

With the context that backwards compatibility means different things for different parties, I'm wondering if versioning is possible while maintaining that changes should be backwards-compatible for data producers. This would keep GTFS easy to use for data producers, while providing a mechanism for data consumers to track added features that break implementation.

Looking forward to thoughts on this from all parties. Thanks!