From owner-freebsd-hackers Thu Oct 17 09:14:56 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA09315 for hackers-outgoing; Thu, 17 Oct 1996 09:14:56 -0700 (PDT) Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.109.160]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id JAA09302 for ; Thu, 17 Oct 1996 09:14:51 -0700 (PDT) Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id LAA00599; Thu, 17 Oct 1996 11:12:31 -0500 From: Joe Greco Message-Id: <199610171612.LAA00599@brasil.moneng.mei.com> Subject: Re: IP bugs in FreeBSD 2.1.5 To: narvi@haldjas.folklore.ee (Narvi) Date: Thu, 17 Oct 1996 11:12:31 -0500 (CDT) Cc: freebsd-hackers@FreeBSD.org In-Reply-To: from "Narvi" at Oct 17, 96 11:06:21 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > This would be, IMHO, an excellent path to follow. 2.1.5 (to become 2.1.6) > > is very obviously a highly polished product, and for many of us would > > continue to be the "OS of choice" for quite some time, for those demanding, > > high availability applications.. > > There are some problems. One of these are ports. Some of ports (SSLeay > for example) do not compile under -stable as they require DES code > present only in -current, all new ports are for -current only and some of > them won't work on -stable as they depend on say TCL being present in the > system. -stable is not only dead it is even buried. And a new release on > -stable will be for only very specific uses and most people perhaps even > wouldn't want it. They just may require all those user programs that are > only for 2.2.x. As much as I like the port paradigm, I think it is mildly broken, and I am sure that others would agree: It is very annoying to try to compile ports more than three minutes after they were created. You will invariably run across a number of them which have changed, some with version number bumps, etc. This is not a FreeBSD problem. However, there are days when I really wish that "distfiles" were somehow managed differently, so that this kind of thing did not happen. > > That's why the 2.2R thing seems like such a good idea. If a new "-stable" > > is created at 2.2R, and "-current" goes its merry way on to 3.0R, that > > gives people like me a good solid point at which to start, and a path to > > follow for the next year or two while 2.2.XR becomes as stable as 2.1.5R. > > 3.0R? wouldn't it be a too high increment in the version number? In that > way we will soon be at FreeBSD 4.3 (and 4.4) release. How about 2.4? It > would allow enough of growing place for 2.2 to evolve into ultrastable > 2.3 (if it stays around for that long). As we seem to be using numbers of > the x.y.z kind we should think too much about x. Or are we going to > undergo some *MAJOR* change? I do not care too much about version numbering. Given the manner in which versions have been numbered, I do not see a need for x.y.z release numbering, and would settle for x.y... but it is really all pretty arbitrary, in my opinion. I do not care if the core team decides that -current after such a fork would be headed towards 2.3, 2.4, 2.5, 3.0, or 10.0.. :-) ... JG