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.
Wine's user-oriented release strategy: when it's ready
Wine has some user-oriented releases in its history: 0.9 (Nov 2005), 1.0 (Jun 2008), 1.0.1 (Oct 2008), 1.2 (Jul 2010), 1.2.1 (Oct 2010), 1.2.2 (Dec 2010), 1.2.3 (Apr 2011), 1.4 (Mar 2012) and 1.6 (July 2013). The next user-oriented release will be 1.8, and will not be for a while yet.
For 0.9, 1.0, 1.2 and 1.4, the Wine team planned the releases by setting criteria and then working until those criteria were met.
For instance, release goals for Wine 0.9 were first proposed at Wineconf 2002 (see WWN 118), and updated over the next year or so, but a code freeze of sorts was not announced until October 2005; release followed promptly in November 2005.
Wine 1.0 release goals were first proposed in May 2000; these were largely met by the time of Wineconf in late 2007, and dates of May and June 2008 were chosen for the code freeze and release.
There are always some criteria available at WineReleaseCriteria
Switch to time-based releases?
Martin Michlmayr's thesis on release management in open source projects gives a good overview of the release management strategy of several large open source projects (Linux kernel, Debian, Gnome, etc.).
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
distributions might break Wine shortly before release, as happened with Ubuntu Hardy with bug 12516.
- 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.)