Redundancy of Spec Rule 3 #6

Closed
opened 2026-02-17 11:01:46 -06:00 by GiteaMirror · 1 comment
Owner

Originally created by @efi on GitHub (Dec 22, 2011).

Hi.

I appreciate your efforts on giving developers a common tool for articulating code changes via version numbers. In that difficult area in the coding field fixed semantics are of real value.

Reading 1.0.0-rc.1 of your Semantic Versioning Specification I wondered, what the purpose of rule 3 is. With the exception of the given examples all specified behavior is repeated in the end of rules 8 and 9.

Could this not be condensed in any way?

Best Regards

Thomas

Originally created by @efi on GitHub (Dec 22, 2011). Hi. I appreciate your efforts on giving developers a common tool for articulating code changes via version numbers. In that difficult area in the coding field fixed semantics are of real value. Reading 1.0.0-rc.1 of your Semantic Versioning Specification I wondered, what the purpose of rule 3 is. With the exception of the given examples all specified behavior is repeated in the end of rules 8 and 9. Could this not be condensed in any way? Best Regards Thomas
Author
Owner

@mojombo commented on GitHub (Dec 23, 2011):

You are correct, rule 3 is redundant. I think I added those points to the 8 and 9 and then forgot to remove rule 3. Will fix.

@mojombo commented on GitHub (Dec 23, 2011): You are correct, rule 3 is redundant. I think I added those points to the 8 and 9 and then forgot to remove rule 3. Will fix.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/semver#6