Time-based releases idea

[Scott Ritchie]

Alexandre Julliard wrote:
> Scott Ritchie <scott at 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