vkd3d release schedule

[Henri Verbeet]

Hi all,

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.

Henri

[Alexandre Julliard]

Henri Verbeet  writes:
> Hi all,
>
> 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.

Sounds good, though early December may be preferable for 1.6, so that it
could be imported into Wine before the start of the 8.0 code freeze.

[Henri Verbeet]

On Thu, 23 Jun 2022 at 10:52, Alexandre Julliard  wrote:
> Sounds good, though early December may be preferable for 1.6, so that it
> could be imported into Wine before the start of the 8.0 code freeze.

Right, that's something to consider. (Although with the more frequent
releases, the diff between 1.5 and 1.6 may not end up being that
significant.)

[Giovanni Mascellani]

Hi,

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).

My two cents, Giovanni.

[Henri Verbeet]

On Thu, 23 Jun 2022 at 12:15, Giovanni Mascellani
 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.