Also the #3677 and #3670 in 8.34.1, and #1715, #286, #283 in 8.35.0
Done, thanks! Hopefully the tool we’re using to auto-generate these gets fixed soon. Word is they’re working on it.
Heh, I got to the latest release before you did
..that’s why you didn’t see them.
I’ll fix the others now…
Do you have a tool you’re using to find these?
Well, with AI, I generated a page for this, page attached in the zip.
index.zip (3.6 KB)
No, this is a separate issue with the same tool.
I changed a setting and pushed another patch release, which is working correctly again now:
This release has the same issue we’ve been seeing with old issues and PRs getting tagged, but I’m going to leave them there for now because we’re working with the GitHub team to get it fixed and I want them to see it.
No word from the GitHub team on this yet.
Can we check with the ADO ppl as well as the issue might in the ADO Github task but not sure who is responsible there ?
cc @RaananW if has an idea ?
An issue is still open with the ADO ppl and I tried to bump the priority, we ll know soon if it will be prioritized. if not we ll do smthg custom I guess ![]()
We’ve made some changes and this should be fixed. What we are doing now is manually creating the release notes from the same scripts that were already updating the CHANGELOG.md in the repo. The GitHub release notes will look exactly like the section from CHANGELOG.md for that particular release. You can see the first one we tested here: Release 8.54.1 · BabylonJS/Babylon.js
That looks good, any intent to fix existing release notes?
I manually updated a few more recent versions, but at this point we aren’t planning to go back and update many old releases.






