-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
update modules to 1.0.1 #10
Comments
👍 for SemVer @kiliankoe Objections with those three? |
BTW I'd propose |
Afaik SemVer basically says anything goes for <1.0.0.
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. |
Fair enough.
I don't get it. Several releases as in |
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. |
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 |
Reminder: Update to |
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. |
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:
validate-fptf
.contributing.md
with a reminder to updatevalidate-fptf
according to FPTF changes – add contributing guidelines #14The text was updated successfully, but these errors were encountered: