AR wrote:
Windows Media Player: 10.00.00.3700
Current Version of Windows: 5.2 (3790.srv03_sp1_rtm.050324-1447)
Visual Basic 6 SP6: 6.0.9782
MSN Messenger: 7.0.0813
Aside from Microsoft's obvious reluctance to make x.1 releases (they don't ring that much in the press), none of the above are any more or less intuitive than 2.16.1. Whether your minor is single digit (Windows, VB, Messenger) or double digit (Media Player), the very moment you start actually
using it, sooner or later you will overflow. Note how Visual Basic is already close to encountering the problem.
No matter whether you just wrap around (NO!), add another digit (intuitive?), or make a major release just to zero-out the minor number (mumblemumble), you don't win anything
except alpha-numerical sortability, and that only in the two cases where you are actually lying about the maturity level of your release...
The Windows version string is a good laugh though, while talking about intuitivity.
The pattern between these is that each number after the decimal place is less significant then the one before, these version numbers fulfill that intuitively...
Until they overflow, a problem that major.minor without leading zeroes doesn't have. That's fixed-width vs. delimited here...
...the version system used in binutils is not intuitive for me, it would be more so if they used underscores or hyphens.
Because the dot happens to be the decimal point in your locale, and you haven't had enough experience to recognize a version number when you saw one (sorry)?
The dot was seperating major and minor version numbers
at least since SCCS came out in 1972, i.e. for all my life (and most likely yours, too). Ever since, developers were familiar with major.minor versioning using the dot as seperator.
You think changing that to a hyphen would be
more intuitive than what everyone has grown to expect? Tradition can become a very strong reason against change, for good reasons, and we're talking one of the oldest traditions in the history of software, here.
I
do admit that the matter had me confused, too, when I first encountered it. But that was the first day I ever ventured beyond my C64, and like, three years
before I first touched a compiler. I, too, argued the wiseness of this, and was told, and listened, and learned. That is what I am trying to do to you ATM, to spare you from carrying a grudge for the rest of your developer existence, since major.minor won't go away.
I added that to Wiki to simply help others who may fall into that in future.
The basic motive is surely applauded. But it's not something that is special to binutils and GCC, or GNU software, as you make it sound. It is about as widespread as calling a file README.txt and expecting people to actually read it.
It's also nice to know that you rate my abilities on my understanding of other people's ideas about how things should be done, because afterall everyone should think the same.
No, that's not the point. If everyone should think the same, we wouldn't be here working on our individual ideas of how an OS should be made.
I know all this sounds pretty offensive, quite probably more than intended. But I think you would have been much more angry had I just deleted the paragraph, that's why I am talking to you in here.
But I think I am justified in rating your
experience on your understanding of something as basic as major.minor.
Leading zeroes is just giving you more time, it doesn't solve the problem. Hyphens or underscores would just be using a non-standard delimiter, and doesn't solve the problem either. Using dates or build numbers removes the ability to tell something about mainlines and code change severty.
If someone comes up with a superior way to do it, I'm all for it, but until then there's something in me resisting change for change's sake.
But I will retire from this argument before offending you more, which was not my intention.
. They usually always follow that rule though.
