[lang_en]
After some waiting, the FreeBSD team will release the 7.1 version shortly. There were a few showstoppers here and there, a security advisory that popped up and needed attention, but we all overcame that and are ready to do the release. Ofcourse that isn't being released as we speak, but it's -very- soon now. 7.1 will kick 2009's ass to begin with. Then followed by a stunning 8.0-release later that year. It promises to be a very good year for us at the FreeBSD development teams, but also for the users ofcourse!.
Please hold your breath and say "ooeeeee ahhhhh" when the release is there!
Enjoy!
[/lang_en]
[lang_nl]
Na lang wachten zal het FreeBSD team binnenkort 7.1 vrij geven. Er waren een aantal showstoppers hier en daar, een security advisory die ertussen kwam en aandacht nodig had, maar deze zijn allemaal overkomen en we zijn klaar voor de release. Uiteraard gebeurd dat niet op stel en sprong, maar dat zal -heel- snel nu gebeuren. 7.1 zal 2009's ass kicken om te beginnen. Daarna zal een geweldige 8.0-release volgen later in het jaar. Dit belooft een schitterend jaar te worden voor ons in het FreeBSD development team, maar uiteraard ook voor de gebruikers!
En nu... de adem inhouden en "Oeeee ahhh" zeggen wanneer de release eenmaal daar is!
Veel plezier!
[/lang_nl]
English 
Dutch 
[...] teigia Remko savo bloge naujoji FreeBSD 7.1 versija pasirodys jau [...]
Exciting! I have some new 1u's waiting for this
Thanks!
To be perfectly honest, I don't believe FreeBSD 8.0 will be ready in 2009. Almost every FreeBSD release has been delayed for quite some time, and 8.0 won't be any different.
My guess is: early 2010
Hi "Anon",
Well, I suppose you are right about the delays and stuff. This time it got delayed by a very long time, which wasn't scheduled etc. We as a team recognize that and are shooting for a different approach for the 8.x branch points.
That said; 8.0 will be a feature rich new platform with many new features build in to the system, which will probably have some fallout in the first 8.0 release (7.0 was very well formed) and will be seen 'unattached' to the 7_branch.
In all: I understand your critisism, which is being worked upon
I seriously believe though that the release of 8.0 will be around the set schedule.
Thanks for the comment! (all others ofcourse as well)
Please don't get me wrong Remko: My comment wasn't supposed to be meant as criticism, but rather as an assessment on how I see the release process
What you could try to do in the future, is to incorporate the previous delays into the next release cycle.
Let's say you're average delay is 5 months. Next time a release schedule is proposed, you "just" add those 5 months and you'll most likely be closer to the actual release date. This worked out pretty good for our own projects.
A good start would be to analyse by how much each release was delayed (starting after 5.0, because it was so special). Calculate the average and add it to the new cycle.
Well, it's healthy critisism so nothing wrong about that. But I also take the assessement part
I think the idea is good in principle, if you have a managing party that actually have something to push (paid employee's can be kicked to work, volunteers can only be asked). I think the main problem with this is that even if we take the delays into account, the release will still shift around because things are found at the latest moment etc (as had happened since the -BETA cycle for 7.1).
So lets say we shift the release date for 8.0 to 1/1/2010. Then (if nothing changes and we continue the way we did) we will release 1/2 or 1/3 in worst case.
What will be happening is that the release engineers will have a revisit of the current procedures, and they will try to change the way the releases work a bit so that a "may 2009" date is a "may 2009' date. That means that revisiting the criticallity of bugs is one of the items, and that people might need to get poked periodically to keep remembering the delivery date. If the work is not done yet, too bad, it will be in the next release. That might be a more agressive way to handle such a release procedure, but it might workout better then accounting the delays and "accepting" them as granted
I still have strong and good faith that 8.0 will be around it's proposed time (it might shift a bit, but the date that will be given will be fairly met).
Suggestions remain welcome!!
One question regarding a release.
The ports tree gets frozen at a time and then enters a slush state, where no major changes could be made.
But the time stamp of the ports are almost 4 months old in the 7.1 relaease.
Is it not better to do the ports freeze when the RC cycles are reached.
Now you have a system when you run portsnap or csup almost all of your ports are outdated.
Including major server parts like apache and so on.
Or are the packages being updated also, if i recall correct the latest packages on the cd are those when the freeze ended.
regards,
Johan
Ooh and a very happy new year to you all!!!
Hi Johan,
Yes, this does sound alarming with 'stale' packages. Critical fixes will get in (security issues) but indeed not many big changes. One thing that had been opted is to indeed start the ports-freeze when the RC-1 is being launced to make the time window a bit more scalable and less long.
That said: one also has to recognize that no matter when the packages will get generated, if the day after that package generation day, a new version of apache will get launched, or MySQL or it will be stale. We ofcourse try to make the 'window of opportunity' as small as possible for that so that you have the most recent, or nearly most recent package available.
I have to admit that I do not know which versions of the packages are there, I think that there is a set generated with RC-1, RC-2 and now for -RELEASE there will also be a set. So what I (emphasis) think is that there will be a rather fresh ports collection on the release media with current packages.
Thanks for the comment and a happy new year to you all too!
7.1 release now can be download on freebsd ftp but still not any news on freebsd page