Whiteboard infinity

Main | Golf handicap system »

Wednesday September 29, 2004

uname -r debate

Never have I thought a simple command can stir up so much passion. The more I dig, the less hopeful I am that any change will be acceptable.

We are our worst enemy

First is the revered taxonomy document. There shall be only 3 components in a release number: major, minor, and micro. All must be numbers whose numerical values can be compared. The value also must be ever increasing, but not necessarily sequential.

Then the fact that Solaris has not used the "micro" component for about 10 years now. The (re)introduction of this concept is to be taken seriously and extremely cautiously. People have written scripts and programs that assume no such component. Once present, these scripts and programs will cease working and hell will break loose.

Philosophically, what exactly is a "micro" release? This thing that we call "updates" are not -- nor are Solaris Expresses. Is it right that their uname -r yield exactly the previous mini-release number?

Application compatibility? Commitments made to customers (implicitly or explicitly)? Tradition? What behavior are we trying to encourage? Rules and policies?

Sigh, again.

posted by syw Sep 29 2004, 05:25:07 AM CST Permalink Comments [2]

Comments:

The difference between major.minor.micro is api.features.bugfixes. It can be argued that any and every patch changes the micro release of the version. When someone writes a script that uses "uname -r" they generally need to know api and features. Thus, you will never be able to change the behavior of "uname -r" to return anything but major.minor. Likewise, if someone does need to know if a patch has been installed, or not, they will continue to use "showrev -p" (at least in the Solaris world).

Posted by Kevin on September 29, 2004 at 07:31 AM CST #

A couple of observations. I've been up in arms about this "uname" thing. That's because I couldn't find an unabiguous statement of what was being proposed. Hence, I went to talk to the source and I find that this is a tempest in a teapot. There are some very minor issues to resolve to clarify the differences between Minor and Patch binding. Although I may agree (mostly) with Sin-Yaw, I'm sorry to say I think Kevin has it wrong and I encourage him to read the relevant documents. A major motivation for restructuring the release taxonomy 7-10 years ago was to allow **new** interfaces to be shipped on a regular and non-disruptive basis. The taxonomy is all about incompatable change, not just change.

Posted by Joseph Kowalski on October 05, 2004 at 07:27 AM CST #