Date: Sat, 02 Sep 2000 19:57:37 PDT From: Stephen Hansen <stephen@cerebralmaelstrom.com> To: John Galt <galt@inconnu.isu.edu> Cc: freebsd-questions@freebsd.org Subject: Re: Why not XEmacs, after all? Message-ID: <200009030256.e832uZS18790@laxmls02.socal.rr.com>
next in thread | raw e-mail | index | archive | help
Okay, I'm not really involved in this conversation but I had to but in a bit, because this argument is just absurd. FreeBSD is constantly under development. There are basically two branches of development -- STABLE and CURRENT. The latter is scary, it has lots of big, experimental stuff going on in it. The former is basically, for the most part, conistant and well.. Stable. People like CD's, it makes things easier, so periodically the development team picks a date and says, `On this date, we are going to make a CD.`. Then, on that day, they grab the entire CVS up 'Stable' and stick it onto a CD. They call that a RELEASE. 4.0-RELEASE is a snapshot of 4.0-STABLE. Once something is RELEASEd, and put on a CD, it can't be changed... so, changes are not made into the RELEASE source-tree, beause that would make it so that /some/ things that say '4.0-RELEASE' are different then /other/ things that say '4.0-RELEASE' There, now that I said that, my responses... "John Galt" wrote: > On Sat, 2 Sep 2000, Ben Smithurst wrote: > > > John Galt wrote: > > > > > So why is it still forbidden in a fresh download? > > > > 4.0 is 4.0, it won't suddenly change. Ever. If you want to use ports, > > cvsup the latest ports tree and you will get no such error. > > And this somehow makes lynx non-deprecated then? To be more precise, I > wanted to use packages, failed, and had to settle with the installed > ports tree: this also failed, so I got the tarball and am now using > lynx. It's not available "out of the box" in a major version release, > this is a result of a policy decision, therefore it may be said that it's > deprecated until such a time as it can be proven that the policy no longer > is in force: one datum is not enough proof in this case, otherwise one > could say that MS-win 3.X was 32-bit, since win 3.11 had some 32-bit > components, and there was a backported fix for win 3.1 called win32s. The fact that lynx is not available in 4.0-RELEASE has nothing to do with a policy change. When they stuck 4.0-RELEASE onto a CD (You know, of the ROM (Read Only?) variety? That you can't change?), Lynx had security holes in it. It is not depcretated. The version available on the RELEASE didn't work right. (snip) > > > > > but until the un-forbid fix propagates, > > > > As it did months ago to those of us who cvsup out ports tree regularly, > > you mean? > > So is 4.0 frozen or dynamic? Or are you not running 4.0 after the first > cvs update? If you can't get lynx in 4.0 (not 4.0 plus a couple of > things), I still say it's deprecated until I see more than one release > reversing the change. You have completly missed something very important: 4.0 != 4.0-RELEASE != 4.0-STABLE != 4.0-CURRENT You can't say "4.0" by itself. 4.0-RELEASE is frozen at the instant it was made; it is a snapshot of 4.0-STABLE. Neither 4.0-STABLE nor 4.0-CURRENT are frozen. I don't see why you don't CVSup _JUST_THE_PORTS_TREE_ which is guaranteed (ish) to work on both -STABLE and -CURRENT. It is seperate from both, because it is a million /seperate/ things that are constantly under development by a million people /not/ related to FreeBSD. You can say itst depcrecated, purple, or a non-text-based browser.. You'd be wrong on all three counts, but hey. Free speech and all. :) --Stephen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200009030256.e832uZS18790>