Slashdot Mirror

← Back to Stories (view on slashdot.org)

FreeBSD Looks Ahead to 6.0

Posted by CowboyNeal on from the pedaling-the-development-cycle dept.

I was catching up on mailing list archives when I came across an announcement from Scott Long of FreeBSD's release engineering team, noting that after the rather substantial amount of time that it took to take FreeBSD 5 to a -STABLE designation, their release schedule will be speeding up in the future. With the official release of FreeBSD 5.3 coming Real Soon Now, a new branch for 6.0 is now tentatively scheduled for mid-2005. It would seem that while the version numbers may increase more rapidly, so will the rate at which new features are merged from -CURRENT, so end users can get new features faster.

6 of 68 comments (clear)

  1. first positive post by Anonymous Coward · · Score: 2, Insightful

    BSD lives!

  2. RTFA -- It's Quite Interesting by akpoff · · Score: 5, Insightful
    1. Move to a timeline-based release cycle rather than feature-based.
    2. Development of major features in Perforce. The goal is to keep the head branch from going unstable very often and allows major features to stay under development if it isn't ready for -STABLE branch point. Appears CVS will still be used for the main tree.
    3. Frequent scheduled releases will keep the bug count under control.
    4. Current plan is to branch for 6-STABLE in the May/June 2005 time frame with 6.1/.2 etc in 4-6 month intervals thereafter.
    Two very big, interesting changes. Given the very usable ports tree moving to scheduled releases for the core system makes a lot of sense. The decision to move development of major features out of the main CVS tree compliments the scheduled-release strategy. If anyone can make it work it'll be the FreeBSD team.

    Congratulations on achieving 5-STABLE and best wishes on 6-CURRENT development!

  3. time-based releases a bad-thing(tm)? by CaptainPinko · · Score: 3, Insightful

    With feature based release you get the pressure to get things done because everyone is waiting for you. I'm worried that with time-based releases a lot of features will languish with tweaking or becoming more and more ambitious and they'll never get finished to be merge since there is no pressure. I'd rather see feature-based for at least one majour feature in a release. In other words keep it feature-based but bite off only a little (and not more than chew) and aim for that bite to be doable in 9-13 months (to leave for debugging, testing, etc.).

    --
    Your CPU is not doing anything else, at least do something.
  4. Re:Private message for Mr. Hawkins by gtoomey · · Score: 3, Insightful

    At the risk of damaging my karma, any post promoting HawkinsOS is a troll.

  5. Re:Kudos by archen · · Score: 5, Insightful

    Now think about this: these developers have kept up with the pace linux development dictates with 1/100 of the resources linux development has.

    That sort of depends on what you mean by resources. An interesting thing was said by one of the DragonFly BSD guys, in that their development moved much more quickly because there weren't as many people involved in the project (as in FreeBSD). It's not neccesarily the size of the team, but the quality and how well they work together. Once you reach a criticle mass for a given team, you end up losing more and more productivity to human overhead as people are added.

    I think Linux may start to feel unnessesary pressure due to corperate interests - which might slow things down more than advance them.

  6. Perforce by Rubel · · Score: 2, Insightful

    Perforce is stable, fast, and well-tested. I don't see how using a great tool is a handicap, even for an open-source project.