Date: Thu, 17 Oct 1996 11:12:31 -0500 (CDT) From: Joe Greco <jgreco@brasil.moneng.mei.com> To: narvi@haldjas.folklore.ee (Narvi) Cc: freebsd-hackers@FreeBSD.org Subject: Re: IP bugs in FreeBSD 2.1.5 Message-ID: <199610171612.LAA00599@brasil.moneng.mei.com> In-Reply-To: <Pine.BSF.3.91.961017105145.17620B-100000@haldjas.folklore.ee> from "Narvi" at Oct 17, 96 11:06:21 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199610171612.LAA00599>