search

public-transport / friendly-public-transport-format

A format for APIs, libraries and datasets containing and working with public transport data.
Creative Commons Attribution Share Alike 4.0 International
125 stars 1 forks source link

update modules to 1.0.1 #10

Closed derhuerst closed 3 years ago

derhuerst commented 7 years ago

For a standard, it is very im important to have specific versions when referring to it. Right now, in npm packages, we just vaguely link to the whole FPTF repo.

I'd suggest to use SemVer for this format/standard. Which would mean that, whenever we make changes that would break FPTF-exposing or FPTF-consuming libs, we increase the major version.

We can use Git tags to mark versions permanently. This is great for technical accessibility (such as using this repo as a dependency), but for greater human accessibility (or visibility if you will), we may also want to use GitHub releases or even publish to npm. Publishing to npm would become especially useful if we added valid and invalid examples of FPTF data to test libraries against.

I started a new project validate-fptf to validate data against the format using JS. I think it makes sense to let this tool's versions follow the FPTF versions.

Decisions to make:

Things to do:

Follow-up after creating a release:

juliuste commented 7 years ago

šŸ‘ for SemVer šŸ‘ for GitHub releases šŸ‘ for npm releases including valid examples to test against

@kiliankoe Objections with those three?

derhuerst commented 7 years ago

BTW I'd propose 1.0.0 as a first release. Below 1.0.0, according to SemVer, every minor version bump is considered breaking. I think that, from the beginning, we should start with a version number that supports non-breaking updates.

kiliankoe commented 7 years ago

Afaik SemVer basically says anything goes for <1.0.0.

Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable.

Which might be helpful to get stuff to a polished point. Otherwise possible mode renames and whatnot could lead to fptf being available in several "initial" releases, which might end up being confusing for people looking to implement it.

derhuerst commented 7 years ago

Afaik SemVer basically says anything goes for <1.0.0. [...] Which might be helpful to get stuff to a polished point.

Fair enough.

Otherwise possible mode renames and whatnot could lead to fptf being available in several "initial" releases, which might end up being confusing for people looking to implement it.

I don't get it. Several releases as in 1.0.0, 2.0.0, ...?

kiliankoe commented 7 years ago

Yeah, several major version bumps. I'm probably one of those people that get to emotionally attached to a version identifier, so please disregard my opinion on this, but I have the feeling that it might be odd for FPTF to be available in version 1.0.0-5.0.0 or so because of tiny breaking changes that force strict major bumps before many people come around to using it.

But yeah, I don't want to get into the way of anything and would still definitely prefer using semver over anything else. And definitely šŸ‘ for using GitHub releases.

derhuerst commented 7 years ago

We can keep using SemVer and make you feel comfortable about the version numbers at the same time. Eventually we'll need to adapt all FTPF-dependent projects anyways, regardless of wether the last/second version is called 1.0.0 or 2.0.0.

derhuerst commented 6 years ago

AFAICT, all of these links should be updated to point to the 1.0.1 version of FPTF specifically:

juliuste commented 6 years ago

36

juliuste commented 6 years ago

Reminder: Update to 1.1.1.

derhuerst commented 3 years ago

Closing this, as the scope of this Issue is a bit too wide. By now, we have FPTF 1.2.1, and many of the mentioned libs are either updated already or obsolete.