mirror of
https://github.com/semver/semver.git
synced 2026-07-11 05:12:48 -05:00
[GH-ISSUE #210] [Proposal] Representing every commit with a unique version elegantly #1005
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/semver#1005
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @hihellobolke on GitHub (Jul 14, 2014).
Original GitHub issue: https://github.com/semver/semver/issues/210
Every commit new version
Every commit (change) creates a new version (appends .1 to the previous version number). So my software v0.1 next commit results in v0.1 (instead of v0.2 which normally is the case) further change results in v0.1.1 & v0.1.1.1 so on. For convenience v0.1.1.1.1 is v0.1(4).
Branching
As code diverges, each new branch gets new version ( it's highest sibling's version + 1). So a branches of parent version v0.1.1 is going to be v0.1.1.2 and v0.1.1.1. Commits to new are 0.1 appends to branch E.g. v0.1.1.2.1.1.1 or v0.1(2).2.1(3)
Vertex is a graph itself
If a vertex version 0.1(32) is a node in graph whose root node is 0, then elegantly 0.1(32).0.1 represents a vertex inside a subgraph 0.1(32) whose root node is 0.1(32).0. This allows extreme flexibility.
Some previous work https://github.com/hihellobolke/trees_of_trees
@crazedsanity commented on GitHub (Jul 14, 2014):
I hope my words do not come off as rude, as that is not the intention.
From these images and explanations, I cannot tell what kind of change was made to the code. I can't find if there's a major change, a minor change, or if there's just a patch. It tells me nothing about the level of change to the code itself.
If I tell my client that "v0.1(55).0.1(43).0.1.3.1(10)" contains a major change...
Nope, I'll stop right there. I don't know what version logically comes next. That massive version numbering scheme is far too complex. It flies in the face of what SemVer is trying to accomplish.
I can tell my client that "v0.1.55" contains a major change. I can tell that client that anything after it will also contain that change, and I would be confident that the client in question would know unequivocally that "v0.2.0" is newer, and that "v0.1.54" is older. I don't even know what would come before "v0.1(55).0.1(43).0.1.3.1(10)," so I would not expect my client to know either.
If I'm missing something here, please let me know. This isn't really stated as a bug fix nor an enhancement.
@hihellobolke commented on GitHub (Jul 14, 2014):
Thats not rude :-) the reason I thought of it as an internal versioning that can be implemented directly in a SCM software where version numbers can always meaningfully pin point to software code at some time in past, and relation between code version in two branches can be identified..E.g. v0.1(55) 's parent is v0.1(54) and v0.1(54).2 is a diverged/branched code. Another reason that I thought was use in a distributed version control, where every developer even committing locally can generate a unique version, also a merge (push) between two version can be identified as well. So peer 2 peer collaboration of code without a central repo may be possible in some manner etc.
For human consumption one could label/tag any vertex 0.1(55) as Release-1.1 or Release-2.0 etceteras which are easier on eyes.
On 15-Jul-2014, at 2:07 am, Dan Falconer notifications@github.com wrote:
@FichteFoll commented on GitHub (Jul 14, 2014):
I'm not sure whether this actually supports the idea behind branches in the first place. (I mean branch commits being independant until merged.)