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

Prior Art: Reviewers Editions #52

Closed
kemitchell opened this issue Jun 30, 2017 · 1 comment
Closed

Prior Art: Reviewers Editions #52

kemitchell opened this issue Jun 30, 2017 · 1 comment

Comments

@kemitchell
Copy link
Contributor

kemitchell commented Jun 30, 2017

Noticed the "versioning" bit in CONTRIBUTING. Folks may be interested in the "Reviewers Edition" system I cooked up for functional prose:

https://www.npmjs.com/package/reviewers-edition-parse

The intended use case was legal forms on commonform.org, but I've applied it to tagged releases on GitHub, as well.

For those coming from SemVer:

  1. No x.y.z software-style numbers, but still machine-readable. SemVer-looking version numbers applied to functional prose can't mean what SemVer says they mean. Versions with different meaning ought to look different.
  2. No 0.y.z "hole" in the semantics.
  3. Direct focus on the message intended from maintainers to consumers, rather than vague functional criteria that only get fuzzier when applied to prose, rather than code. New Reviewers Editions tell users what they should review and assess, based on the Reviewers Edition of the copy they're already using.
@mlinksva
Copy link
Collaborator

mlinksva commented Jul 1, 2017

Thanks for pointing out this prior art. It is very close to the twist on SemVer we came up with:

BEIPA CONTRIBUTING Reviewers Editions
MAJOR version when objectives of agreement change. A company using BEIPA would have to fully evaluate a new major version to determine fit. When authors recommend users review a new edition in its entirety to ensure it meets their needs, they increase the edition number.
MINOR version when agreement changes do not change objectives of agreement but are substantial enough to merit legal scrutiny from any user. When authors recommend users review at least the new or changed parts of a new edition, they increase the update number.
PATCH version for corrections which any user would likely want to accept with minimal additional review. When authors make only typographic or other, minor corrections that users need not review, they increase the correction number.

I like your take because it's more general, and even more accurate for the potential version 2 of BEIPA (the objectives haven't really changed, but it is a big enough change to fully re-evaluate).

I'm not really thrilled with lack of 0 and .. The result, eg BEIPA 2e or eventually BEIPA 2e1u5c and similar looks really foreign, or rather computer-y and maybe (ironically) not intended for consumption by most humans, though I appreciate the direct focus on the message.

Maybe we should use your definitions but stick with SemVer formatting. 🤔

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

No branches or pull requests

2 participants