5 ms·

Two big problems with this: - Does not support multiple release tracks. What if you have 'version 1' and 'version 2' with both receiving updates? - Cannot vis

Two big problems with this: - Does not support multiple release tracks. What if you have 'version 1' and 'version 2' with both receiving updates? - Cannot visually guarantee that any version is greater than, less than, or equal to another. If you're using git, mercurial, or any other VCS with hash-based commit IDs, how can a user tell which release for a particular day is the latest? This is probably fine for SaaS stuff where you only support one version at a time and the version number is more important to you than your users.

kazinator 7y ago
When version 1 receives an update, that's how we got version 2. The update to version 2 is version 3. I don't see what is here to misunderstand. If someone wants to take just a subset of the changes between 2 and 3 (say just one fix) and backport it over version 1, they are on their own. That's a downstream problem that the project doesn't have to cater to in its versioning scheme. The project issued a bugfix, and that bugfix was applied when version 2 was superseded with 3; end of story.
- deleted 7y ago
  [deleted]
- hvdijk 7y ago
  The problem was not with a random someone wanting to make a change to version 1, it was with the project wanting to make a change to version 1. That is not a downstream problem.
- rusticpenn 7y ago
  The problem with this is that it is not practical. One example I can think of on the spot is an old tool written to support Windows 7, a bridge version supporting win 7-10 and a new version supporting only 10. Most industries do not move at the same pace (We have some projects that can only run on Windows 95). So some security updates to the bridge version adn the new version are made simultaneosly and corresponding update to their version numbers. Another example is python 2 and python 3, where python 2 was getting updates form 5+ years after python 3 released.
  - kazinator 7y ago
    Python 2 and Python 3 are different languages that get installed side by side. Two completely independently developed C compilers, or independent implementations of Common Lisp are much more compatible with each other than are Python 2 and Python 3. They could as well have different names (think Perl vs. Rakudo). Racket is more compatible with Scheme than Python 3 is with Python 2, yet has a different name, for good reasons. Both Python 2 and Python 3 could respectively use a simple versioning numbering scheme. Python 3 version 1, version 2, version 3, ...
NetOpWibby 7y ago
The example I gave on the site with "UI and implementation" branches could work. I haven't done this in practice so I cannot confirm. Idk how you'd be able to tell anything about a commit from its hash tbh. You're right though, I primarily create/work on SaaS products and this versioning is perfect for it.
- saxonww 7y ago
  I think my original reply was a little brusque. Really this is a fine scheme, but I do think it's limited in where it can realistically be used - IMO, small self-contained SaaS products only - and I do think that the hash should be called out explicitly as metadata vs. an integral part of the version. Simply moving from YEAR.MONTH.DAY.CHANGE_ID to YEAR.MONTH.DAY.UPDATE.CHANGE_ID, with UPDATE being a mandatory monotonically-increasing integer, would make this scheme more attractive to a wider variety of users.

kazinator 7y ago

When version 1 receives an update, that's how we got version 2. The update to version 2 is version 3. I don't see what is here to misunderstand. If someone wants to take just a subset of the changes between 2 and 3 (say just one fix) and backport it over version 1, they are on their own. That's a downstream problem that the project doesn't have to cater to in its versioning scheme. The project issued a bugfix, and that bugfix was applied when version 2 was superseded with 3; end of story.

deleted 7y ago
[deleted]
hvdijk 7y ago
The problem was not with a random someone wanting to make a change to version 1, it was with the project wanting to make a change to version 1. That is not a downstream problem.
rusticpenn 7y ago
The problem with this is that it is not practical. One example I can think of on the spot is an old tool written to support Windows 7, a bridge version supporting win 7-10 and a new version supporting only 10. Most industries do not move at the same pace (We have some projects that can only run on Windows 95). So some security updates to the bridge version adn the new version are made simultaneosly and corresponding update to their version numbers. Another example is python 2 and python 3, where python 2 was getting updates form 5+ years after python 3 released.
- kazinator 7y ago
  Python 2 and Python 3 are different languages that get installed side by side. Two completely independently developed C compilers, or independent implementations of Common Lisp are much more compatible with each other than are Python 2 and Python 3. They could as well have different names (think Perl vs. Rakudo). Racket is more compatible with Scheme than Python 3 is with Python 2, yet has a different name, for good reasons. Both Python 2 and Python 3 could respectively use a simple versioning numbering scheme. Python 3 version 1, version 2, version 3, ...

NetOpWibby 7y ago

The example I gave on the site with "UI and implementation" branches could work. I haven't done this in practice so I cannot confirm. Idk how you'd be able to tell anything about a commit from its hash tbh. You're right though, I primarily create/work on SaaS products and this versioning is perfect for it.

saxonww 7y ago
I think my original reply was a little brusque. Really this is a fine scheme, but I do think it's limited in where it can realistically be used - IMO, small self-contained SaaS products only - and I do think that the hash should be called out explicitly as metadata vs. an integral part of the version. Simply moving from YEAR.MONTH.DAY.CHANGE_ID to YEAR.MONTH.DAY.UPDATE.CHANGE_ID, with UPDATE being a mandatory monotonically-increasing integer, would make this scheme more attractive to a wider variety of users.