[GH-ISSUE #210] [Proposal] Representing every commit with a unique version elegantly #7113

New Issue

GiteaMirror · 2026-06-20T16:52:32-05:00

GiteaMirror commented

2026-06-20 16:52:32 -05:00

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

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) ![untitled untitled - cacoo 2014-07-15 01-09-06 2014-07-15 01-09-16](https://cloud.githubusercontent.com/assets/2939715/3576071/b2617312-0b8e-11e4-8968-1e3750af4b2f.png) #### 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. ![untitled untitled - cacoo 2014-07-15 01-19-45 2014-07-15 01-19-47](https://cloud.githubusercontent.com/assets/2939715/3576207/1f0a330e-0b90-11e4-88f1-dd9d50884d0b.png) Some previous work https://github.com/hihellobolke/trees_of_trees

GiteaMirror closed this issue

2026-06-20 16:52:33 -05:00

GiteaMirror commented

2026-06-20 16:52:34 -05:00

@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.

@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.

GiteaMirror commented

2026-06-20 16:52:35 -05:00

@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:

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.

—
Reply to this email directly or view it on GitHub.

@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: > 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. > > — > Reply to this email directly or view it on GitHub.

GiteaMirror commented

2026-06-20 16:52:36 -05:00

@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.)

@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.)

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/semver#7113