Alexandre Julliard wrote:
Scott Ritchie scott@open-vote.org writes:
The alternative, truthfully, is choosing between shipping Ubuntu with a 2+months out of date Wine version or an untested one. Either option sucks.
I don't see how we can possibly have a tested release ready every time some distro decides to ship. On the contrary, since distros don't give a damn about Wine and usually do their best to break it (page zero issue anyone?), we are better off releasing after a major distro release so that we have a chance to find and fix the latest breakages first.
Why not target Wine around the beta release? That way we still have time to change and fix things that have to be done at the distro level. For instance, during the Ubuntu Hardy beta, I found a handful of bugs that required changes in other packages than Wine, such as missing 32 bit versions of some of the libraries.
If we had committed Ubuntu to release with an older version of Wine that didn't have those features, those bugs wouldn't have been found in time for our dependencies to be fixed. Users who managed to get the newer release of Wine (such as from our website or with Ubuntu backports) would have that feature permanently broken until the next Ubuntu release, and in the meantime we'd likely get a bunch of bad bug reports.
Let's face it, we effectively have time-based releases now, since with the features-based model 1.0 kept getting pushed back for years and years. Now, that we've finally set a date, we're actually going to have one ;)
It's still very much a feature-based model, only of course the desirable features have been shifting as Microsoft shipped new stuff and people wanted to run new apps before we supported the old ones properly... A deadline is of course necessary at some point, but the date was only set once we got to the point that a release looked within reach.
Fair enough. There really is nothing wrong with what happens in practice: tons of ambitious new features are targeted for the next major release, then after the date is set and begins to approach things get more aggressively triaged. You are, of course, free to delay a release pending whatever feature you think is both doable and critical.
Of course our next releases hopefully won't take 15 years each, but I think it's too early to say if the next release will take 6 months or 2 years.
We don't need to make a new major release every 6 months for things to time well, just some multiple of it. The main benefit is the same as having the biweekly releases - more users with a newer Wine.
I can't say for sure as I haven't worked on Wine C code, but I don't think even an ambitious 6 month release cycle puts us in danger of having a dramatic amount of lost work. The move to GIT has likely helped a lot, as its relatively easy to maintain branches for a feature that won't make it into the next release. If the stable release is at the wrong time, a developer could practically ignore the release entirely and simply have his changes merged in later.
The biweekly release has served us very well, and it seems reasonable to extend this sort of regularity to stable releases. Wine obviously shouldn't recommend a particular distro or anything, but my experience with Ubuntu and Wine has taught me that there are some very real and tangible benefits to timed releases. March and September seem like as good months as any.
Thanks, Scott Ritchie