From owner-freebsd-hackers Sat Mar 9 00:25:57 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id AAA02094 for hackers-outgoing; Sat, 9 Mar 1996 00:25:57 -0800 (PST) Received: from haywire.DIALix.COM (root@haywire.DIALix.COM [192.203.228.65]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id AAA02083 for ; Sat, 9 Mar 1996 00:25:17 -0800 (PST) Received: (from news@localhost) by haywire.DIALix.COM (8.7.4/8.6.12) id QAA00535 for freebsd-hackers@freebsd.org; Sat, 9 Mar 1996 16:27:02 +0800 (WST) X-Authentication-Warning: haywire.DIALix.COM: news set sender to usenet-request@haywire.dialix.com using -f Received: from GATEWAY by haywire.DIALix.COM with netnews for freebsd-hackers@freebsd.org (problems to: usenet@haywire.dialix.com) To: freebsd-hackers@freebsd.org Date: 9 Mar 96 07:32:17 GMT From: peter@jhome.DIALix.COM (Peter Wemm) Message-ID: Organization: DIALix Services, Perth, Australia. References: , <199603071649.JAA14066@phaeton.artisoft.com> Subject: Re: When is 2.2 Estimated to be released? Sender: owner-hackers@freebsd.org X-Loop: owner-hackers@FreeBSD.ORG Precedence: bulk terry@lambert.org (Terry Lambert) writes: >> > Uh, what exactly would 2.2 have, then, if none of the planned major >> > features made it in? >> > >> > Something like that should be called 2.1.1, not 2.2.0, IMO... >> >> At least it would have the improved VM code, Paul's new cool malloc(), >> better Linux emulation, and a newer ports collection. Even with no other >> features, this is at least deserving of 2.1.5, if not 2.2.0. Also, >> remember that -current has been a separate branch of the tree, with many >> improvements stretching back to six months before 2.1.0-RELEASE! >> >> Or we could do like Microsoft and wantonly bump version numbers at will. >> I know, let's call it FreeBSD 4.0 to keep it in version parity with >> Windows 95.. ;-) Recent MS examples: Office 95 (all programs were >> bumped to 7.0, even though Word was 6.0 and Powerpoint was 4.0 formerly), >> and Visual C++ (which went from 2.2 to 4.0 to keep it in parity with >> MFC).. The point I'm trying to make is that version numbers are >> ultimately arbitrary; I think it would be foolish to bump it up to >> 3.0-RELEASE if we didn't add any major features, but there's nothing >> stopping us. 2.2-RELEASE sounds perfectly fine. >I'd like to see the code differential from 2.1.0 to 2.1.5 be the same >as the code differential between 2.0.5 and 2.1.0. Dont forget, doing a side release branch is a trememdous amount of work, as I'm sure David G. will testify to. All effort spent on the side-branch is directly taken away from major features in -current. >We've already established the value of a 0.0.5 increment. >What I think the improvements you noted represent is ~0.0.1 compared >to the increment change for 2.1.0. The improvements noted are only a small fraction of what's been going on. There are a lot of general cleanups and improvements in -current that have been done and largely glossed over. Dont forget that -current and -stable diverged at 2.0.5 release. They have been diverging so much that backporting stuff from -current into -stable is starting to consume a non-trivial amount of effort. >I think a 2.1.5 would have to include fixes to the install process >(without breaking gzip image loading). >I think a 2.2.0 would need to include the PCMCIA support and the >4.4BSD-Lite2 integration, which were announced for it. I hear that the 4.4Lite-2 integration for the kernel is basically done and due for commit any minute now. An interesting point: If the -stable branch was not consuming the amount of maintainence time that it has been, we'd most likely _have_ 4.4Lite-2 and PCMCIA integration, as well as a greatly debugged vm, vfs and kernel. It's unfortunate that "real-world" constraints required things to be done the way they were. :-( >Just my opinions, though... Also, dont forget that things like FS layering, VFS cleanups, etc are being put off because of the amount of effort being diverted to maintaining the older code trees. Since these are very dear to your heart, I'd expect you'd be the last person suggesting diverting more effort away from what might have been spent looking at the changes you want to make. > Terry Lambert > terry@lambert.org >--- >Any opinions in this posting are my own and not those of my present >or previous employers. -Peter