As I covered at the end of the dev chat yesterday (logs), we’re planning for 3.5 Beta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. 1 next week. This gives us a week to land a lot of things.
I’ve updated the teams and tasks page. Everything is moving along nicely! Solid pace everywhere. There’s also a UI-specific progress report from @lessbloat on make/ui.
Ship early, ship often. This is expected to be a very rough cut beta. I called it “scrappy,” and not in the pugnacious way. After that, the plan is for a new beta every week. By beta 3 or so, major features should be pretty well shored up.
Some background on this: As I mentioned during the chat, I really want to make sure we have strong pre-release participation. After studying the last five release cycles, I noticed that earlier and less stable betas can encourage this. When we ship more polished betas, it seems people pick up on that, and it feels like less testing occurs. Additionally, we’ve sometimes gone a month or more between the first and second beta. Rather than slowing down, beta should be the time we speed up!
So, by week 6 or so, we should be ready to transition out of bug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority.-fix mode and into RC One of the final stages in the version release cycle, this version signals the potential to be a final release to the public. Also see alpha (beta). mode. I’m excited! Who’s with me?