vkd3d release schedule

Henri Verbeet hverbeet at gmail.com
Thu Jun 23 11:33:12 CDT 2022

On Thu, 23 Jun 2022 at 12:15, Giovanni Mascellani
<gmascellani at codeweavers.com> wrote:
> Il 23/06/22 09:49, Henri Verbeet ha scritto:
> > As you may have noticed, the time between the vkd3d 1.3 and 1.4
> > releases was a fair bit shorter than the time between the 1.2 and 1.3
> > releases. That was deliberate; at the start of the year the plan was
> > made to aim for about 4 vkd3d releases per year. I think that has
> > worked out well so far, so we'd like to continue along those lines. In
> > practical terms, that puts the tentative release dates for vkd3d 1.5
> > and 1.6 at late September and late December this year.
> Shall we also define a freeze schedule, possibly a bit more in advance
> than we did this time?
> For 1.4 we had a soft freeze (API and architecture) and a hard freeze
> (only important bugfixes), both a week long. In practice during the soft
> freeze there were two accepted patch sets (one by me with matrix
> support, which was mostly discussed before freeze anyway, and another by
> Biswapriyo with some IDL additions) and one during the hard freeze
> (essentially doing the release itself, plus a small bugfix).
> I would propose to have a significantly longer soft freeze (at least a
> month) so that API has to be frozen well in advance, and a slightly
> longer hard freeze, but with a perhaps wider filter (e.g., two weeks,
> during which only important bugfixes to the main code are accepted, but
> it is still possible to commit pretty much everything to testing code,
> tests and documentation). Ideally this would allow us to consolidate
> work in tests and docs (not that the situation is terrible in vkd3d, but
> it's not bad to have some time specifically dedicated to that).

I think that broadly makes sense, yes. It would mean we'd need things
to be ready to be committed during the first half of the release
cycle, because we'd be in various levels of frozenness during the
second half. Conceptually that's similar to the Linux "merge window"
model; there's certainly something to be said for that model.

More information about the wine-devel mailing list