From Wikipedia - Debian In July 2002, the Project released version 3.0, codenamed woody, a stablerelease which would see relatively few updates until the following release.
It was a bit more than 2 years.Also, Debian is a full distro with all software, while Haiku is only an OS and will let you update specific software in the timeframe between two os versions. No one has problem with Windows release cycle, and it can be much more than 2 years... Our system will be more like that, not a fully frozen set of software without a single change for two years. I think it should aim for stability rather than feature creep. Each new release should improve a defined set of things, and the alphas should aim to test these features. That's what was done for ATA in alpha 1, for example. It could be done for web browser and/or locale kit in some future previews (be it before or after R1 - locale kit should be after if we keep the 'fully beos compatible' goal).
Anyway, the Debian vs Ubuntu part was not about the timings, more about the way it's planned : Ubuntu sets a date and try to cram in as much features as possible. Debian list the features they want, and take the needed time to make the release bugfree. It does not work so well for them because it's too long for a whole linux distro. With better control, I think we can make it and still have reasonably short time between major versions. And I'd be fine with a 2-year time between releases. Some people are even still running R5 as of today (well, not so much, but I'm sure there was a lot more in 2003)
If 2 year release is fine for most then you can install Alpha1 and run it for 2 years without any updates and see how happy you are inSept 2011. Many would be unhappy doing this. Using nightlies is an option but they may be buggy, unstable and unpolished - not ideal for general use.
I was meaning between official releases (R1, R2). Normal people shouldn't care about the alphas. So, having 2 years between R1 and R2, you can have 3 alpha/beta versions in between
Ingo makes a good point that for minor changes, 6 to 7 months is good. For major changes ( going alpha to beta, beta to RC, etc. ), then longer time frame could be required, like maybe 9 to 12 months. I still prefer6 to 9 month release cycle myself, which feels right, and just disable any unfinished or broken features in the release.
I don't want to upgrade my OS every 6 months. An upgrade always mean some things will break and you'll spend time fixing them up. But it's worth it as it brings much new features you may (or may not) need. So yes, there coulb be alphas every 6 months, but look at how it was done until now : bugs that we want solved for R1 are tagged R1 in trac, other are tagged "unscheduled". So, R1 is a feature-based release. Now, alphas and betas are meant to give part of the work more exposure, so I can't see how it makes sense to have them done at fixed date and without feature plan. When you release an alpha, the release notes should say what you expect users to do with it, what they should look at. It can also serve as an help for developpers to spot compatibility problems in their software before the final stable release comes in.
It does not mean we're going to spend 2 years between each alpha, just that we should keep planning them on a feature basis. Now, up to you to decide how many features you think we can get done in 6 months, but if the estimation is wrong, better delay the release than do it anyway without what was planned.
-- Adrien Destugues / PulkoMandy http://pulkomandy.ath.cx