Date: 9 Mar 96 07:32:17 GMT From: peter@jhome.DIALix.COM (Peter Wemm) To: freebsd-hackers@freebsd.org Subject: Re: When is 2.2 Estimated to be released? Message-ID: <peter.826356737@jhome.DIALix.COM> References: <Pine.AUX.3.91.960306172218.27009B-100000@covina.lightside.com>, <199603071649.JAA14066@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?peter.826356737>