On Monday 05 May 2008 05:13:16 Dan Kegel wrote:
I just wrote up an idea related to release management for post-1.0 wine releases. It's online at http://wiki.winehq.org/TimeBasedReleases Essentially, the idea is to release in March and September, in time for the April and October releases of Ubuntu.
For instance, following this strategy, we might plan to release wine-1.2.0 in September 2008 or March 2009.
I'm against September, as it means we'll go into code freeze _again_ just before Summer of Code finishes.
While I agree that bi-annual releases sound like a good thing, I'm opposed to forcing it just to make Ubuntu's 8.10 schedule with 1.2.
Also, I'm not really sure what this'll mean in terms of features and bug fixes. We certainly don't want to keep people hanging without fixes for bugs for half a year.
We also don't want to slow down development more than needed.
Now, as you state on the wiki page, a bi-weekly release schedule is good for early adopters and developers, as it's centered on "Get my new cool feature in!" rather than on "Will this break Photoshop?". But, and I see you mention that yourself, "Will this break Photoshop?" is a really hard question to answer, especially for developers who don't own photoshop.
Bi-annual releases are good for people who already have their apps working, as prior to a release we probably should make sure nothing breaks. But as fixing new bugs sometimes is a bit hit-and-miss, only being able to try for the wider public once every six months isn't too great.
So assuming we manage to get wine test failures down to 0 during this code freeze, I'm happy to make sure none of my patches breaks anything there. If I can get a similar website for the apps we really don't want to regress, I'll of course try the same for that. But before we don't have that, I don't think it's a good idea.
Cheers, Kai