Hi, I have some feedback, I’m not sure if this is the best place to leave it, but if not I hope some of you can take it to the right people.
Something I’ve noticed is that in the article for each release, there is some tendency to leave the “Known Issues” section with a template saying there is none.
In both cases, the releases are marked as having no known issues. This honestly has greatly discouraged me from trying newer versions in the future.
I know this is normal, it’s difficult to avoid having any regression in behavior in a program with so many use cases, but I do think there should be more effort in keeping the article updated with changes in behavior in the given release, or at least have some way to tag GitHub issues as introduced in a release and have a link to those in the article (the current link takes you to the 9K+ open issues in the whole project).
If I would know TileMaps could not be copied in 4.3.dev3 I would never have tried it (and the bug was reported by the time I downloaded it). I was hoping these articles to warn me about it, I went through each of them between my previous release and dev3, and the articles gave me the impression there were no regressions.
Can you point to some known issues introduced by these versions? New issues on the tracker doesn’t mean issues caused by recent releases, plenty of issues are introduced by old code and only discovered later, so please show some examples ones that haven’t been solved
I don’t understand, do you use x.dev, x.beta, etc. versions for development? I guess that can’t even be accepted as a problem… it would probably be better to use a version marked as stable
Well, I gave 3 examples, the tilemaps thing is solved, but the changes in “Snap 2D Vertices to Pixel” and the Github issue mentioned before (related to animation) are changes in behavior when I moved from Godot 4.2 to 4.3.devX. I know we can think of those as bugs, or just “changes” because of X or Y enhancements, but at the end of the day they regress the behavior I used to get in the previous version.
New issues on the tracker doesn’t mean issues caused by recent releases
That’s exactly my point, it would be great to have a way to know what bugs have been identified in each release, and have the Known Issues section of the article updated accordingly.
I think you missed my point. I’m not complaining there are bugs in dev versions, I’m saying it would be good to have a way to track regressions caused by a release, or changes in behavior developers are expected to adapt to when uptaking a version.
For example, it would be great if dev4 article would contain a note saying:
If you notice rotated pixel art graphics look weird after uptaking this version, try unchecking “Snap 2D Vertices to Pixel”
This would most of the time be done after release, which is a lot of work to maintain, it’s very rare that we discover a bug between releases like that and pin them down before it’s released, further it’s a lot of unnecessary work to do this to even older versions, so it would only make sense to update the latest one, it doesn’t make sense to update dev3 after dev4 is released
I agree, but what do you think about this potential solution: in Github add tags to indicate the version in which a bug was found, then people can just filter for those issues, and you could have a filtered link in the release’s article.
So if I’m moving from 4.2 to 4.3.X, I would look at these lists and evaluate if the reported issues are something I’m concerned about or not. In this way it’s not manual work, and it is up to the community to keep the issues correctly tagged to help others.
As a maintainer that would be a lot of work, and it would add to the already large responsibilities with managing bug reports, it’d always be manual work, also adding that many new tags would make it impossible to work with them, it’s cluttered as it is some times
ones that haven’t been solved