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
Henri Verbeet hverbeet@gmail.com 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.
On Thu, 23 Jun 2022 at 10:52, Alexandre Julliard julliard@winehq.org 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.)
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.
On Thu, 23 Jun 2022 at 12:15, Giovanni Mascellani gmascellani@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.
-
Alexandre Julliard -
Giovanni Mascellani -
Henri Verbeet