> > For these reasons, in my humble opinion, choosing our software packaging > format and guidelines (of which version numbering is but a single > aspect) is NOT A TRIVIAL EXERCISE and is not as simple as picking an > off-the-shelf format. (I wish that the reality were otherwise).
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. 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. 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. 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.
_______________________________________________ Devel mailing list [email protected] http://lists.laptop.org/listinfo/devel
