Subject: Re: next stable release version number (was re: Semaphore p1003.1b)
To: Marc Tooley <>
From: Bill Studenmund <>
List: current-users
Date: 10/06/2003 17:50:12
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Oct 01, 2003 at 02:48:00PM -0700, Marc Tooley wrote:
> On Wednesday 01 October 2003 13:05, Manuel Bouyer wrote:
> > On Tue, Sep 30, 2003 at 09:16:19AM -0700, wrote:
> > > I always like the fact that we were still at version 1.6 while the
> > > rest of the world was moving on towards version 9.8 or 12.3 so it'd
> > > look good to the unwashed masses.

:-) We aren't going to 2.0 because it looks good. :-)

We've always said that when we have SMP and thread, we'll have 2.0. For a
number of reasons (many technically sound and more than just, "we said
so"), when the number for the next release was decided, 2.0 was chosen.

> > The issue here is that with our current version numbering scheme:
> > x.y.z, y is bumped for major releases and z for minor, bug-fix
> > release. So x is never bumped, and will say at 1 forever. So just
> > drop x, and start using 2 digit version numbers :)
> But, but.. I thought the fact we were still at 1.x.x was a simple=20
> against-the-grain statement making light of the fact that everyone and=20
> their dog bumps their major version numbers five or six times a year? I=
> thought it was a great nose-thumbing, personally. Otherwise we'd be at=20
> 6.2 or so right now. Just feels wrong.
> I think if MP and SA can be forced into the stable (ha ha) that would=20
> justify the move to 2.x.x, but let's still have the three version=20
> numbers, I say. :)
> If it's bound to be 2.x, near as I can tell the following major=20
> functionality has been added/modified:
> 1. Semi-functional MP
> 2. Mostly functional scheduler activations
> 3. Updated compiler
> Any other major changes? Are #1 and #2 in a state to be released as=20
> stable? I've been reading some messages suggesting that there are=20
> certain hard problems that won't be solved anytime soon without=20
> significant effort on the part of Some Brave Soul Out There.

There are a whole slew of changes. My understanding is we have very=20
functional big-lock SMP. We also have very functional SAs. At work, I've=20
developed a multi-threaded ap that has taken quite a pounding, and runs=20
well. The changes to fix upcalls during falts seem to be helping a lot=20
too. So it seems we're well past mostly-functional.

Take care,


Content-Type: application/pgp-signature
Content-Disposition: inline

Version: GnuPG v1.2.3 (NetBSD)