-
Notifications
You must be signed in to change notification settings - Fork 11
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
Remove falsy tests #12
Conversation
There where also some opinions against this. As it's not clear if we keep the PR at the end, let's discuss this in the next call. |
Hmm my point is that as it stands, the test suite is actually enforcing undefined behavior. That does not align with the interface spec. It's okay if people end up amending the spec but these test cases did not see much PR review. Can we compromise by at least commenting them out for now? Right now the suite is actually prohibiting me from publishing for this reason. |
The compromise would be OK for me, but I have no idea how to handle that with sem versioning. As an alternative you could use a temporary git dependency in your project. Also if you are talking about a full release and not just a beta or release candidate, I'm not sure if you do yourself a favor. The outcome of the discussion could be also that we change the spec. That would be a breaking change in your code. |
If I understand correctly, the goal of this package is to implement a spec. It currently deviates from the spec by enforcing undefined behaviour. According to semver I'd say this is a patch version (internal change that fixes incorrect behavior aka bugfix)? |
We never discussed this, but in my opinion it's not one way from the spec to this repo. If we find differences or gaps, first we have to decide where to make the fix. That decision was not made yet. So semver would need to cover a possible future patch version, not an actual patch version. IMHO a git branch is the right tool for this case. @RubenVerborgh you have any feedback? It's your code from 417efb2 which I have merged. |
I remember a discussion with @blake-regalia, where he was convinced: rdfjs/data-model-spec#132 (comment) |
@RubenVerborgh I'm still on the fence, I'd like to hear what others have to say on the call. Let's keep this PR and the issue open for now and i'll just use the branch as @bergos suggested. |
Obsoleted by proposed resolution rdfjs/data-model-spec#142. |
Closes #11