<div dir="ltr"><br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
For these reasons, in my humble opinion, choosing our software packaging<br>
format and guidelines (of which version numbering is but a single<br>
aspect) is NOT A TRIVIAL EXERCISE and is not as simple as picking an<br>
off-the-shelf format. (I wish that the reality were otherwise).</blockquote><div><br>Absolutely agreed.  Except the part where we can't choose a version format without resolving all other issues. I think it is clear what we want from a version format: some simple, human-readable, comparable numbers. <br>
<br>If we want anything more, it ceases to be a version format and inevitably becomes something far more complex. Which we may decide to implement, although in the conversations you reference I was the very one suggesting we wanted more complex things sooner, and I was shot down, I think justly. The use case for versions is NOT source control, or keeping a record of forking history, or determining network interoperability, or determining Glucose version interoperability, or determining of identity relations, or determining journal instance interoperability. <br>
<br>All of those are separate issues we will face one day, sooner or later, and I doubt we will even look at the version numbers in the solution to any of those. Versions are JUST for human-readable distinctions between two versions of the same activity [in the future, "the same" will imply "signed"], with the ability for humans or Glucose to make a reasonable (not bulletproof) inference about which one has the maturer code. I think that the rpm solution is just that, a solution.<br>
<br>Note: regarding the fact that versions are useless for determining identity (whether two xo's are identical): this is currently ALL we use versions for. This is bug 7534, which I will now nominate for 8.2.</div></div>
<br></div>