How Should a GTFS Publisher Version a Schedule Feed?
From the earlier reference collection. Read the current software blog.
A schedule release should be identifiable as a coherent dataset and retrievable from a public location whose purpose does not change between releases.
Treat each release as a dataset
A GTFS dataset is a complete set of files, so a published revision should be handled as one release rather than as a loose collection of independently replaced tables. If a download combines a new trips.txt with an old calendar_dates.txt, a consumer may receive relationships that never existed in the publisher’s intended schedule. Assemble and validate a release before making it available, then preserve its files together as a unit.
Give the artifact an identity
A version label, release date, or other revision identifier helps a consumer distinguish one schedule from another. The label should identify the dataset, not imply that the schedule is valid on a particular day unless that is actually what it means. For example, a publisher might name an archived file transit-2026-11.zip and keep a short release note stating which service period it represents. The precise naming scheme is a publisher choice; consistency and clarity are the point.
The GTFS reference recommends publishing datasets at a public, permanent URL, including the ZIP file name. A predictable address allows a consumer to retrieve or cite the intended release later. It is useful to keep a stable page or directory for current access while preserving version-specific artifact names for historical identification.
Separate the stable address from the changing data
A publisher may offer a convenient “current feed” address that points to the latest release, but consumers need to know that the contents can change. For reproducible analysis, a version-specific download is more useful because the same address continues to identify the same artifact. If a file must be corrected, publish a clearly identified replacement and explain the correction rather than silently changing the meaning of an already cited revision.
For example, documentation can list a current-feed link for routine applications and an archive of named releases for audits. A downstream project that needs repeatable results can pin one archived release, while a live application can intentionally follow the current version.
Publish the context consumers need
Include enough release information to tell a person what they downloaded, when it was published, and how it relates to earlier revisions. Make sure the public link works without relying on a temporary session or a private workstation path. A compact release note can describe corrections or schedule changes in plain terms. Stable identification does not guarantee that every consumer will interpret the feed identically, but it makes the underlying input inspectable and repeatable.