Image by Andrew Mason via FlickrJaunty should be out today (this post is scheduled), and I think this is a good time to talk about whether timed releases are a good idea. I'll put my opinion out here at the beginning and say that, from a project management standpoint, hard release schedules are really not the way to go. Let's look at Ubuntu 9.04 Jaunty as an example.
There's a giant bug in Brasero that doesn't let a user create a video CD or DVD. Brasero claims to have this function; it appears to have this function by virtue of there being a button for it; but attempts fail because it claims that it's not possible with the available plugins. This also breaks Totem VCD/DVD writing, one of the bullet points for this release. A fix is available and in a PPA, but it's apparently (as of T minus one day) not going to be included because of the package freeze. They can't test the package and get it included in the CD on time.
That leaves a choice: push the release back a couple of days, or ship with a major bug.
Canonical used to be a little more flexible with its shipments: 6.06LTS (Dapper Drake) was delayed two months because they wanted to hammer out a few bugs. About the time that 8.04LTS came out, though, Canonical became much more serious about the day they were to release on. Countdown clocks were part of the marketing effort, and if they're showing a release but one doesn't appear, that looks really bad for the project.
As a result, 8.04LTS (Hardy Heron) shipped with a bug which prevented F-Spot from launching a second time on AMD64. The first time worked, but a late change in mono left the default photo application for the OS segfaulting on startup when run the second time. It didn't get fixed for a couple of weeks. Ubuntu 9.04 (Jaunty Jackalope) will likely have a similar (but not quite as serious) bug in the shipping version because of Brasero.
There's the other side of the argument which says that there'll always be bugs and that you just need to ship, anyway, but that's why some bugs are called "release critical" and you need to correct them if at all possible. That "posible" thing includes delaying the release for a week.
Timed releases are fine, but don't shoot yourself in the foot. Be flexible enough to put out a good product. You can't be taken seriously by real users if you ship non-functioning product regularly. That's the big picture.