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

Alternative #6

Open
jeremykohn opened this issue Jul 29, 2021 · 2 comments
Open

Alternative #6

jeremykohn opened this issue Jul 29, 2021 · 2 comments

Comments

@jeremykohn
Copy link
Contributor

Thank you very much for your work on SemVerDoc! I've found it useful and I'm sure others have as well.

Recently I've worked on developing an alternative versioning scheme for documents -- following SemVerDoc's structure, but with categories that are purely qualitative (current SemVerDoc is both qualitiative and quantitative).

The new versioning scheme would be as follows:

  1. MAJOR: Changes to the document's substance.
  2. MINOR: Changes to the document's style but not its substance.
  3. PATCH: Corrections of errors in spelling, grammar, or spacing.

Comparison to current SemVerDoc (as of 1.2.0):

Version SemVerDoc Qualitative only
MAJOR Significant changes. Substantive changes.
MINOR Adding or removing information. Stylistic changes.
PATCH Minor changes (e.g. fixing typos). Error corrections.

Something to consider for SemVerDoc 2.0?

@ooker777
Copy link

ooker777 commented Mar 1, 2024

What is the difference between significant changes and substantive changes? Also, I add or remove information, then according to this scheme, it should always be a MAJOR increment, right? Regardless on how I feel insignificant/insubstantive it is?

@ooker777
Copy link

ooker777 commented Mar 2, 2024

Before knowing about SemVerDoc, I have been using this scheme for writing projects:

  1. MAJOR: significant changes in root folder
  2. MINOR: significant changes 1st-level folders
  3. PATCH: significant changes in 2st-level folders

What is significance is up to you. For me, it may be adding or removing a file or folder. Renaming without changing the idea much may be denoted with a letter after the number (i.e. 33a3b). If your root folder's structure is already stable before you apply the versioning, and you foresee that it will be stable in a far future, then you can skip the MAJOR version if you want.

This idea can be generalize to any hierarchical structure, not just limited to folder structure. For example, a hierarchical graph.

I'm not sure if this idea is useful. Any feedback is welcomed.

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