OSDev.org

I just found this recent edit in the Wiki, I presume by AR who got bitten by this (see GAS .code16):

Note: The versioning scheme used is that each fullstop seperates a full number, eg. 2.8.0 2.9.0 2.10.0 2.11.0, this may be confusing if you're used to Windows' program's schemes or even just basic math (eg. 1.01 1.02 etc).

I want to reassure myself that we are still targeting that FAQ at people who are competent enough to tackle an OS development project of their own.

Major.minor has been in use for decades, for just about every software product out there, including all Microsoft products before they went first '95 and then .NET. To be exact, even the .NET runtime is currently v1.1 IIRC, not 1.01...

The only reason you don't see x.10 releases too often these days on Windows machines is that it has become en vogue in the "pro" sector to make a new x.0 release every other month and let the maintenance rot. I, however, seriously doubt Apple will stop patching MacOS after v10.1.9 (current is v10.1.7).

Not trying to put too fine a point to it, but if such a thing is a "frequently asked question" or a necessary reminder for an OS-level developer... no I won't say. I just fear that we might be getting overboard in catering for people who shouldn't be that close to source code anyway.

Am I alone in this?

Hi,

Solar wrote:I want to reassure myself that we are still targeting that FAQ at people who are competent enough to tackle an OS development project of their own.

The problem here, as I see it, is that if the FAQ was targetted at people who are already competent enough to tackle an OS development project, then it wouldn't need to contain anything.

IMHO the FAQ is for people who are trying to become competent in areas of OS design and implementation where their current knowedge may be lacking - Bill Gates might use it to brush up on his low level protected mode knowledge, Dennis Ritchie might need to research GUI design, Steve Jobs might be trying to figure out Intel's APIC chips.

That said, I also think the FAQ should have a clear concise list of "assumed knowledge", like knowing how to program in your chosen programming language, knowing how to work with different number bases, knowing what a CPU/memory/hard drive is, etc. The list could also contain URLs for other sites ("How to Program in C" or "Basic Computer Hardware" for example) that people can go to if they don't quite have the assumed knowledge.


Cheers,

Brendan

Ok, I'll play this game:
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

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, the version system used in binutils is not intuitive for me, it would be more so if they used underscores or hyphens. I added that to Wiki to simply help others who may fall into that in future.

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.

What I don't understand is things like "linux-2.6.11-gentoo-r9". Surely if you're using version numbers you don't need the "r9" tacked on the end - wouldn't "linux-2.6.11.9-gentoo" or "linux-2.6.119-gentoo" or even "linux-2.6.12-gentoo" be more consistant?

Anyway, UNIX is an abbreviation of "Undeniably Not an Intuitive eXperience" . I assume people who don't agree with this wouldn't be writing an OS...


Cheers,

Brendan

I must admit that I got tricked by version numbers of MySQL the other day. My common sense told me that 3.23.58 < 3.23.6 and that 3.23.6 == 3.23.60 .

IMHO the ability to understand version numbers isn't a requirement for OS development. As long as you can code the language and read technical docs, you've got a chance. I suspect that the people who learnt programming by themselves rather than through any form of education (e.g. me) miss out on these minor details, as they are pretty arbitary

Pete

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.

version numbers ... well, I remember being tricked by them once or twice a while ago just out of them being crazy like hell. That's been a learning experience.

@ Pete: even "educated" ppl can stumble upon this trap - for they aren't prepared for it despite having their heads full of knowledge - same as you and me. Admittedly, the educated ppl have more words to express their frustration. *chuckle*

What I don't understand is things like "linux-2.6.11-gentoo-r9".

That happens when you have an "upstream" package (linux-2.6.11), to which you apply your own build-scripts, patch-sets or metadata.

In this case, Gentoo offers different patch sets for the kernel. Unchanged kernel sources would be linux-2.6.11-vanilla, alternatives being e.g. linux-2.6.11-mm etc.

The trailing -r9 defines the version of the downstream package, e.g. how often the Gentoo package maintainers have re-packaged the linux-2.6.11-gentoo package.

Another reason why arbitrarily switching to hyphens wouldn't be so good an idea. The Gentoo package maintainers, at minimum, would hate your guts for it.

bickering about version numbers isn't necessary I daresay.

But I reckon, some sentences have been misunderstood here heavily and angry subtones came out of that.

Just breathe and turn off your brains for a few seconds, and then, after cooling down, turn them on again. It helps wonders. *gg*

Nevertheless, I'm looking forward to having a fine afternoon in the sun today - some biking, some running, what so ever. No hankering to turn on any computer. *gg*

I already learned from my mistake in the original thread, my comment about the versioning system itself was simply an acknowledgement that I was wrong but I was venting my frustration at something that was obvious but hadn't been explained to me.

But as I do not use Linux very often, on Windows each developer tends to like to come up with there own versioning scheme (PowerDVD 6.0, Azureus 2.3.0.4, Nero 6.6.0.. They usually always follow that rule though.

FWIW, I think this particular version number confusion (as it relates to binutils) is fair game for the FAQ. Whether we're all supposed to understand that particular versioning convention or not, it's always possible for the eyes to trick the brain, as it did in this case. If the explanation in the FAQ will help others avoid the same problem, I say let it stay there.

I like major.minor, and avoiding leading zeros. However, I think as a compromise there should be more major releases to zero things out and avoid these kinds of problems.