From owner-freebsd-current  Sun Feb  9 10:54:24 1997
Return-Path: <owner-current>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id KAA29938
          for current-outgoing; Sun, 9 Feb 1997 10:54:24 -0800 (PST)
Received: from nic.follonett.no (nic.follonett.no [194.198.43.10])
          by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA29925
          for <current@freebsd.org>; Sun, 9 Feb 1997 10:54:14 -0800 (PST)
Received: (from uucp@localhost) by nic.follonett.no (8.8.5/8.8.3) with UUCP id TAA14579; Sun, 9 Feb 1997 19:50:05 +0100 (MET)
Received: from oo7 (oo7.dimaga.com [192.0.0.65]) by dimaga.com (8.7.5/8.7.2) with SMTP id TAA03061; Sun, 9 Feb 1997 19:48:18 +0100 (MET)
Message-Id: <3.0.32.19970209194817.00b06db0@dimaga.com>
X-Sender: eivind@dimaga.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Sun, 09 Feb 1997 19:48:27 +0100
To: asami@vader.cs.berkeley.edu (Satoshi Asami)
From: Eivind Eklund <eivind@dimaga.com>
Subject: Re: conditionally including <sys/param.h>
Cc: gjennejohn@frt.dec.com, current@freebsd.org
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-current@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

At 01:25 AM 2/6/97 -0800, Satoshi Asami wrote:
>Also, I would like to propose to have osreldate updated in a way that
>all 2.1*s come before all 2.2*s and they come before all 3.*s.  As
>seen in the recent top port debacle, simply using the release
>year/month is bound to utter confusion.
>
>Right now we have (from the handbook):
>
>===
>2.0-RELEASE:                    199411
>2.1-current's:                  199501, 199503
>2.0.5-RELEASE:                  199504
>2.2-current before 2.1:         199508
>2.1.0-RELEASE:                  199511
>2.2-current before 2.1.5:       199512
>2.1.5-RELEASE:                  199607
>2.2-current before 2.1.6:       199608
>2.1.6-RELEASE:                  199612
>2.2-RELEASE:                    199701
>3.0-current as of Feb 1997:     199702  (will certainly be bumped)
>===
>
>Obviously everything up to 2.1.6R can't be changed, but the last two
>are still salvagable.  Let's say we make them
>
>===
>2.2-RELEASE:                    199707
>3.0-current as of Feb 1997:     199801
>===
>
>so we have more space to squeeze in 2.1.7R and 2.2.5R and such without
>sacrificing the linear ordering.

I disagree.  I think we should make them
2.2-RELEASE:                     2200000
3.0-current:                     3000000

with LOADS of space to mess around in, and not something looking like dates.

Eivind Eklund perhaps@yes.no http://maybe.yes.no/perhaps/
eivind@freebsd.org