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.

Sign up for GitHub

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

Version numbers #13

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
+8 −0
Open

Version numbers #13

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
da2e2ce
Version numbers
plehegar Jan 7, 2021
e3c3795
Update index.html
plehegar Jan 8, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 8 additions & 0 deletions index.html
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -274,6 +274,14 @@ <h3>Document Title</h3>
convention.</p>

<p>Capitalize title words following U.S. usage.</p>

<p><code>Part_Number</code>, edition number, and <code>Version_Number</code>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would treat Part_Number and edition number separately as I would only expect integers in these cases. That is, "Groovy API Part 2" looks good but "Groovy API Part 2.3" seems wrong. Similarly, "Groovy API 2nd Edition" looks good, but not "Groovy API 2.3 Edition".

SHOULD take the form X.Y.Z where X, Y, and Z are non-negative integers, and MUST NOT contain leading
zeroes. X is the major version, Y is the minor version, and Z is the patch version. X, Y and Z are separated
by '.' (DOT). Y and Z are optional (2, 2.0, 2.0.0 are equivalent).
Each element SHOULD increase numerically. Major version one (1.y.z) is for initial development. For additional
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Usually, Semantic Versioning uses 0 Major for initial development and 1 first public release. Even though we do everything in public the transition from 0 to 1 does indicate a commitment to new stability. Is that not relevant for this use?

https://semver.org/#spec-item-4
https://semver.org/#spec-item-5

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right but there are no W3C specifications which do this. It would also break pubrules: FPWD to CR would be v0 and then the PR and Rec would be 1.0; then the next version would also be 1.0 until it moved to PR.

I think this would be super confusing.

So best to say that specification versions do not follow Semantic Versioning in this regard.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK - Got it
Perhaps spell it out rather than leaving it as a possible type-o?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about adopting a suffix notation on the version, so Rec would be 1.0.0, then next update might be 1.1.0[-suffix] or 2.0.0[-suffix]? This is often done on GitHub repos that use semantic versioning.

We could be clever about the suffix we use - instead of "-RC" for Release Candidate, we could put the maturity level, i.e. -WD or -CR etc. The idea is only to remove the suffix when publishing ("releasing") as a Rec.

considerations, one may see also <a href="https://semver.org/">Semantic Versioning</a> if applicable.
</p>
</section>

<section id="Editors">
Expand Down