Date: Wed, 24 Nov 1999 23:09:14 -0700 (MST) From: "Forrest W. Christian" <forrestc@iMach.com> To: Cy Schubert - ITSD Open Systems Group <Cy.Schubert@uumail.gov.bc.ca> Cc: Mike Tancsa <mike@sentex.net>, stable@FreeBSD.ORG Subject: Re: speaking of 3.4... Message-ID: <Pine.BSF.3.96.991124223734.18017E-100000@workhorse.iMach.com> In-Reply-To: <199911241545.HAA97726@cwsys.cwsent.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hmmm.... I guess I've been following this thread long enough to form an opinion or at least an idea. For "core" server machines, following each and every release can be too much work and too risky to do on a 3-4 month basis - specifically if your upgrade may have an effect on many users. However, in order to keep up with the security fixes which are necessary to survive in the environment of today's internet you need to keep up with the latest code. Hard Decision... Do you upgrade and risk screwing something critical up, or do you not upgrade and risk being intruded/DoS'd? Maybe it would be cool if we actually had three chains. You have a "major" release once a year. Call it something like "MISSIONCRITICAL" or something like that. Once it is branched, integrate ONLY security and bug fixes into it. Minimize the impact, where possible, of upgrading so people feel reasonably secure in the fact that the upgrade will be safe. This is the architecture Cisco takes with their routers. For example, Cisco's "current" version is 12.0.x. They "created" 12.0 by merging all the code together and labeling it 12.0(1). (Ala 4.0-CURRENT). They also indicated that 12.0(1) was "early deployment" code - meaing late beta and that people shouldn't run it unless you need the 12.0 feature set. NO NEW FEATURES are added to the mainstream 12.0 release. In fact, they don't even add support for new hardware. 12.0(2) just fixes releases in 12.0(1) and 12.0.(3) fixes bugs in the previous two (and regression issues). So, as long as your hardware is supported in 12.0, you can keep going with the "mainstream" 12.0 release. At some point (like 12.0(3)) it is declared "limited deployment" meaning ok, but may have some bugs, and then later "general deployment" meaning, considered stable. At some point they retire the 12.0 chain and move to 12.1 which re-integrates features. 12.0 gets supported with bug fixes until 12.2 or 13.0 comes out or so - or maybe better put, until they have a couple later "general deployment" releases. Now, let's assume you want/need new features and/or new hardware support. You then pick an appropriate "release chain". For example 12.0 T is what they call the "Consolidated Technology Early Deployment" chain. This is essentialy the equivalent of the FreeBSD -RELEASE set. Features get added to this as needed and all the newest "STABLE" features are there. In addition, additional hardware support gets added here also. They also release code which is equivalent to a -STABLE "snapshot". For instance, I have a router which has a 4 port ATM card in it which isn't supported in 12.0 or 12.0T. As a result I get to run 12.0XK. The next version of 12.0T will support this card, and then version 12.1. Generally, I like to run a mainstream release such as 12.0, but as necessity requires me to run a XK release, I have to do so. As soon as the next T release comes out I will move back there. There is also a development chain which is equivalent to -CURRENT. You have to specifically request this and you need to pretty much agree that if you use this you know you're going to have problems. A description of cisco's release method is at the following url: http://www.cisco.com/warp/public/cc/cisco/mkt/ios/rel/prodlit/537_pp.htm It would be really cool if FreeBSD would be able to do something like this. In other words, I have to upgrade all my systems once a year and apply "bug fixes" the rest of the year. - Forrest W. Christian (forrestc@imach.com) KD7EHZ ---------------------------------------------------------------------- iMach, Ltd., P.O. Box 5749, Helena, MT 59604 http://www.imach.com Solutions for your high-tech problems. (406)-442-6648 ---------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.991124223734.18017E-100000>