cmd.foo(...); cmd.bar(...); cmd.baz(...); is nice, having to construct three different cmds and determine which to use when is less nice
I think this is a drawback of the per-extension fn structs paradigm, though maybe solveable at a higher level by bundling things up?
another thing that's on my mind a bit is that the prevalence of Vulkan feature flag gated functions kinda undermines the upsides of per-extension fn structs, since many core functions may or may not be available
problem:
RenderPassMultiviewCreateInfo does not implement ExtendsRenderPassCreateInfo2
it (like most such things) only implements
ExtendsRenderpassCreateInfo
looks that way, there's exactly one instance of
structextends="VkRenderPassCreateInfo,VkRenderPassCreateInfo2"
Indeed, and it isn't on
VkRenderPassMultiviewCreateInfo at least. Perhaps this is already reported as an upstream bug, otherwise worth reporting it or contributing a fix over at Vulkan-Docs?
Ralith: What about current open PRs, shall we merge the whole bunch of breaking PRs soon-ish and cut Ash 0.37?
1 reply
Haven't seen any activity on
ash_window::enumerate_required_extensions usability issue #595, but that's ash-window which can live on its own release schedule
I'd rather merge breaking PRs sooner rather than later and open a backport branch for nonbreaking stuff if needed, it's hard to keep track of a bunch of unmerged stuff and conflicts can be an issue
Yeah we can probably merge anyway and cut a backport branch if we really see a need to
Just want to avoid releasing multiple breaking versions in short succession
Though OTOH it makes the "migration" process smoother for those affected by multiple breaking changes
bunching them up? yeah, but you can do that regardless with backports, just a matter of policy
and whether you want to do more work tracking unmerged stuff and resolving conflicts or writing backports
Not afraid for backports anyway, once we cut a new release we can just do non-breaking followup releases with new nonbreaking features
But we generally haven't needed those, it's not like any release really broke
It's only for the odd case where someone really insists on needing a certain fix/feature on a specific version because they can't upgrade to the newer ash, but that has never happened thus far
I mean as a matter of routine practice, we could consider master to always be the next breaking release, and also merge non-brekaing PRs to the latest backport branch
Not sure how I feel about preliminary picking of non-breaking changes to a backport branch
In any case, my worry was more about doing lots of breaking releases in quick succession, but I think we can do one now
But yes, maintaining a backport branch and eagerly merging breaking changes to
master would alleviate that somewhat... 🤔
higher constant overhead, lower per-PR overhead, unclear where we're at on that axis
have seen it work well for really really big repos but we arguably are not there yet
just food for thought
so long as you're the one keeping track of what needs to be merged I'm not gunna complain :D
Yeah I definitely hope we're not big enough for that :D
I guess I'll just go start merging PRs then
Shall we get MaikKlein/ash#597 in first and keep that as the last non-breaking commit in the event that we'd like some backports?
You'll probably have to rebase your PR a bit then, new functions and all...
Perhaps @MaikKlein should change the PR settings to require everything to be based off of main before we can click merge
(That should also automatically show an "update branch" button in GH UI)
Because then at least we'll have the CI - in particular the generator run - against main always
Otherwise it'll only start erroring about missed generated changes after being squash-merged on top
And so I saw the wrong 1.3.207 title (should have been .208) as I clicked merge
Oh well :D
rebased 599, and added a second commit with some cosmetic internal cleanup
Nice touch, did I really go against the status quo and use the function call for
1.3 only?
I only see
.fp_v1_3() calls, nothing else 🙈
I'll try to publish a new release tomorrow unless anything else comes up
Also just dropped some branches related to bors or associated with a closed PR. @MaikKlein Anything else we can remove from https://github.com/MaikKlein/ash/branches/all?