All, The following is the approximate schedule for FreeBSD releases in 2006: Jan 30: Freeze RELENG_5 and RELENG_6 Mar 20: Release FreeBSD 6.1 Apr 3: Release FreeBSD 5.5 Jun 12: Freeze RELENG_6 Jul 31: Release FreeBSD 6.2 Oct 23: Freeze RELENG_6 Dec 11: Release FreeBSD 6.3 A 'freeze' means that the tree will be closed to changes except with specific approval, and the focus will be on producing, testing, and fixing release candidates. The release dates are targets that we hope to make, but we will continue with the policy of only releasing once all of the showstoppers are cleared, i.e. we will release when it is ready. FreeBSD 5 5.5 will be the final release from the RELENG_5 tree. We are doing it to provide support for users who have committed to FreeBSD 5 and who need more time to transition to FreeBSD 6. However, in order to keep forward progress with FreeBSD 6, we will produce this in parallel with the 6.1 release, and thus it will not be our main focus. Users who are using FreeBSD 5 are strongly encouraged to evaluate FreeBSD 6. After this final release, the security team will provide security update support through 2007. FreeBSD 6 There will be three FreeBSD 6 releases in 2006. It will be our primary focus for bugfixes, performance enhancements, and incremental functionality and driver additions. There will likely be one more release in 2007, after which we will begin focus on FreeBSD 7. FreeBSD 7 We will start preparing for FreeBSD 7.0 in June 2007. I'll hopefully update the release engineering pages soon to reflect this. If you have any questions, please feel free to contact me and the rest of the release engineering team. Thanks!ott Scott
On Fri, Dec 16, 2005 at 12:04:05AM -0700, Scott Long wrote:> All, > > The following is the approximate schedule for FreeBSD releases in 2006: > > Jan 30: Freeze RELENG_5 and RELENG_6 > Mar 20: Release FreeBSD 6.1 > Apr 3: Release FreeBSD 5.5 > Jun 12: Freeze RELENG_6 > Jul 31: Release FreeBSD 6.2 > Oct 23: Freeze RELENG_6 > Dec 11: Release FreeBSD 6.3 > > A 'freeze' means that the tree will be closed to changes except with > specific approval, and the focus will be on producing, testing, and > fixing release candidates. The release dates are targets that we hope > to make, but we will continue with the policy of only releasing once > all of the showstoppers are cleared, i.e. we will release when it is > ready. > > FreeBSD 5 > 5.5 will be the final release from the RELENG_5 tree. We are doing it > to provide support for users who have committed to FreeBSD 5 and who > need more time to transition to FreeBSD 6. However, in order to keep > forward progress with FreeBSD 6, we will produce this in parallel with > the 6.1 release, and thus it will not be our main focus. Users who are > using FreeBSD 5 are strongly encouraged to evaluate FreeBSD 6. After > this final release, the security team will provide security update > support through 2007.Sounds like an ambitious schedule... All my FBSD servers are at least up to 5.3; my laptop is happy at 5.4. I have what I believe to be a rationalquestion. Why should I go beyond v5.5? More to the point, why can't minor security tweaks be maintained indefinitely for 5.5? What will releases -6 and -7 offer that can;t reasonably be dropped into -5? gary -- Gary Kline kline@thought.org www.thought.org Public service Unix
Gary Kline wrote:> On Fri, Dec 16, 2005 at 12:04:05AM -0700, Scott Longwrote:> >>All, >> >>The following is the approximate schedule forFreeBSD releases in 2006:>> >>Jan 30: Freeze RELENG_5 and RELENG_6 >>Mar 20: Release FreeBSD 6.1 >>Apr 3: Release FreeBSD 5.5 >>Jun 12: Freeze RELENG_6 >>Jul 31: Release FreeBSD 6.2 >>Oct 23: Freeze RELENG_6 >>Dec 11: Release FreeBSD 6.3 >> >>A 'freeze' means that the tree will be closed tochanges except with>>specific approval, and the focus will be onproducing, testing, and>>fixing release candidates. The release dates aretargets that we hope>>to make, but we will continue with the policy ofonly releasing once>>all of the showstoppers are cleared, i.e. we willrelease when it is>>ready. >> >>FreeBSD 5 >>5.5 will be the final release from the RELENG_5tree. We are doing it>>to provide support for users who have committed toFreeBSD 5 and who>>need more time to transition to FreeBSD 6. However,in order to keep>>forward progress with FreeBSD 6, we will producethis in parallel with>>the 6.1 release, and thus it will not be our mainfocus. Users who are>>using FreeBSD 5 are strongly encouraged to evaluateFreeBSD 6. After>>this final release, the security team will providesecurity update>>support through 2007. > > > Sounds like an ambitious schedule... All my FBSDservers> are at least up to 5.3; my laptop is happy at 5.4.I have> what I believe to be a rationalquestion. Whyshould I go> beyond v5.5? More to the point, why can't minorsecurity> tweaks be maintained indefinitely for 5.5? Whatwill> releases -6 and -7 offer that can;t reasonably bedropped> into -5?A "me too" here for 5-Stable. I have a test PC, that was running 5-Stable using an additional swapfile to extend swap space. Never any problems at all with 5. After upgrading to 6-stable, I got regular hang-ups of the system (endless loop?) when swapspace is used extensively. Never happened with 5. I wild guess of mine is that there's problem with the 'enhanced filesystem access' in 6. I've reported this issue, and also provided backtraces of kernel dumps, although I'm not an expert in kernel debugging. However, no reponse so far. For me 6, as of now, is not yet as stable as 5 used to be. Regards, Rob. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
On 12/16/05, Scott Long <scottl@samsco.org> wrote:> FreeBSD 7 > We will start preparing for FreeBSD 7.0 in June 2007. > > I'll hopefully update the release engineering pages soon to reflect > this. If you have any questions, please feel free to contact me and the > rest of the release engineering team. Thanks!ottThere have been some questions on the lists about what to expect from release x.y and I personnally have always looked at the TODO list like http://www.freebsd.org/releases/6.0R/todo.html For 6.0 I noticed there were more updates on that page for bugs and their fixes than for features per se. My sugestion, maybe at a first stage setting the TODO list has it's advantages, one knows what to expect from a release, it's clearly stated and documented there and the developers can see their goals. This is valid for minor and major releases of course. How about it? -- Joao Barros
On Fri, December 16, 2005 11:45 am, Frank Mayhar said:> Well, there is _one_ reason. I, too, have (almost) all of my machines > up to 6-stable, with the very notable exception of the one that runs > asterisk. Unfortunately, last I looked, the zaptel drivers hadn't been > ported to 6. I found this out the hard way when I upgraded and my VOIP > setup failed spectacularly. I then downgraded back to 5.4 and have been > there ever since, siiigh. --The zaptel drivers are working fine on 6, check the archives of the asterisk-bsd list: http://lists.digium.com/pipermail/asterisk-bsd/2005-December/001363.html The latest asterisk from CVS HEAD compiles and runs very well on FreeBSD 6-STABLE -give it a try. -kim -- w8hdkim@gmail.com
On Fri, Dec 16, 2005 at 12:04:05AM -0700, Scott Long wrote:> There will be three FreeBSD 6 releases in 2006.While this is nice, may I suggest that it is time to put aside/delay one release cycle and come up with a binary update mechanism supported well by the OS? Increasing the speed of releases is good. Increasing the number of deployed systems out of date because there are no easy binary upgrade mechanisms is bad. It has been bad, it's getting worse. -- Jo Rhett senior geek SVcolo : Silicon Valley Colocation
Joe Rhett
2005-Dec-17 14:00 UTC
Fast releases demand binary updates.. (Was: Release schedule for 2006)
On Fri, Dec 16, 2005 at 12:04:05AM -0700, Scott Long wrote:> There will be three FreeBSD 6 releases in 2006.While this is nice, may I suggest that it is time to put aside/delay one release cycle and come up with a binary update mechanism supported well by the OS? Increasing the speed of releases is good. Increasing the number of deployed systems out of date because there are no easy binary upgrade mechanisms is bad. It has been bad, it's getting worse. -- Jo Rhett senior geek SVcolo : Silicon Valley Colocation