Skip to content
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

Closed
9 tasks done
derhuerst opened this issue Oct 19, 2017 · 10 comments
Closed
9 tasks done

update modules to 1.0.1 #10

derhuerst opened this issue Oct 19, 2017 · 10 comments

Comments

@derhuerst
Copy link
Member

derhuerst commented Oct 19, 2017

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:

  • use SemVer?
  • GitHub releases?
  • npm releases?

Things to do:

Follow-up after creating a release:

@juliuste
Copy link
Member

juliuste commented Oct 23, 2017

👍 for SemVer
👍 for GitHub releases
👍 for npm releases including valid examples to test against

@kiliankoe Objections with those three?

@derhuerst
Copy link
Member Author

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.

@juliuste juliuste added this to the 1.0.0 milestone Oct 24, 2017
@kiliankoe
Copy link
Member

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
Copy link
Member Author

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
Copy link
Member

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
Copy link
Member Author

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
Copy link
Member Author

derhuerst commented Dec 15, 2017

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

@juliuste
Copy link
Member

#36

@juliuste juliuste changed the title publish a first release update modules to 1.0.1 Mar 27, 2018
@juliuste juliuste removed this from the 1.0.0 milestone Jun 25, 2018
@juliuste
Copy link
Member

Reminder: Update to 1.1.1.

@derhuerst
Copy link
Member Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

3 participants