Time Based Releases

Wine's developer release strategy: once per two weeks

Wine has had an excellent time-based development release strategy for years: release every two weeks. This is great, as it gives early adopters an easy way to try fresh Wine, and it provides nice labels to hang bug reports on. This should continue unchanged.

These releases are not really suitable for the general (non-early-adopter) public, though, as they are expected to fluctuate in quality as risky new changes are merged and debugged.

The general public needs what is called a user-oriented release, where great care is taken to make sure there are no brown-paper-bag bugs, and that common use cases work well.

Many of these projects are moving towards a time-based release strategy, i.e. they announce their release date well in advance, and any feature that doesn't look like it's going to be ready in time simply gets deferred until the next release.

This lets users plan ahead. It also enables coordination between different open source projects.

For instance, Ubuntu releases each April and October, and Fedora seems to release in May and November. Gnome does its releases in March and September; this means that Ubuntu and Fedora can ship with an up-to-date version of Gnome. (And it probably also means that Fedora benefits from the bugs reported by Ubuntu users. )

The idea was discussed on wine-devel, and Alexandre was not convinced. His objections seem to be:

code freezes and QA are too expensive to do every six months

Perhaps a prerequisite will be some way to reduce the cost of QA, e.g. by using AustinEnglish's Appinstall (an automated application test suite).

This is less likely to happen once Wine becomes an indispensable part of life, e.g. once it can run most of the latest Adobe suite.

it would be bad to ship with a broken feature (e.g. what if we merge the DIB engine feature, and it doesn't work yet?)

The traditional solution there is to only merge major changes once they're in good shape, and to do it shortly after a release rather than shortly before one. If it's not ready, just defer it to the next release. (This is of course useful only if you're doing frequent releases; it sounds horrible if you're used to doing releases every two years.)