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

Should we version validation_codes.md? #553

Closed
zimeon opened this issue May 27, 2021 · 3 comments · Fixed by #556
Closed

Should we version validation_codes.md? #553

zimeon opened this issue May 27, 2021 · 3 comments · Fixed by #556
Labels
Editorial Editorial issues (no changes to intent)
Milestone

Comments

@zimeon
Copy link
Contributor

zimeon commented May 27, 2021

I think when we created https://github.com/OCFL/spec/blob/main/validation/validation-codes.md we imagined consistency of error and warning codes between versions. I think we should certainly maintain this but I think we should version the validation codes file (perhaps move it into the spec directory) because:

  1. How do we add a new error code in draft or for a new version without creating confusion? E.g. Conformance of prior versions #550
  2. Even if we maintain codes, we may change descriptions from version to version
@zimeon zimeon added Editorial Editorial issues (no changes to intent) Needs Discussion labels May 27, 2021
@zimeon zimeon added this to the 1.1 milestone May 27, 2021
@awoods
Copy link
Member

awoods commented May 31, 2021

Yes, moving the validation/ directory into draft/ as siblings of 'spec/' and 'implementation-notes/' would be helpful.

@zimeon
Copy link
Contributor Author

zimeon commented Jun 1, 2021

Would it be better/simpler to have validation_codes.md in the spec directory instead?

@awoods
Copy link
Member

awoods commented Jun 1, 2021

As long as the validation_codes.md lives in "draft/", and subsequently "1.1/", "2.0/", etc... I am fine with locating it within "draft/spec/" or "draft/validation/".

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Editorial Editorial issues (no changes to intent)
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants