Hi!
After using Cocos Creator for over a year now I’ve come to the conclusion that this project should really improve some aspects of its management and development.
These past 2 or 3 days I spent my time trying to find the root cause of a bug (regression) that was introduced in the latest version of Cocos Creator. I finally found that this issue was introduced by this pull request (and I’ve since opened a new pull request to fix the issue).
Now obviously bugs and regressions are an inevitable part of software development but when I looked at this pull request I’m kind of surprised at how this code has passed the review process. There is no explanation or reasoning provided in the pull request and the code simply removes a functionality without providing any replacement. It seems like the review process is not strict enough to prevent these kind of regressions from happening.
The reason that I’m complaining about this is that this has been a constant issue for me while using Cocos as a user/developer. Every version of Cocos that I’ve used (starting from v3.2) to develop my game, I eventually ended up encountering a game-breaking bug that I couldn’t find a workaround for. Now if I’m lucky the bug will get fixed in a new version. But unfortunately the new version will have its own bugs and regressions that weren’t present in the previous versions! And so this cycle continues ad infinitum.
Right now it feels like Cocos does not have a single stable version that I can rely on. I really hope that at some point in the future, there would be a lot more focus on stability and fixing bugs instead of adding new features. Even the Unity engine has adopted this approach for the last few years, they used to have 4 feature releases every year but now they reduced it to 2 feature releases per year but with many more bugfix releases.
Totally agreed with you, i understand why it’s going on. Well, i wish they have their own “Linus Torvalds” as general maintainer of the engine and investors must to understand that why it’s so important, not just focus on Chinese markets and mini games on them.
I think this PR will solve your problem. The reason for the problem is that DragonBone is syncing the bone transform to the nodes only during the rendering phase, when the physics has already been updated. The fix is to change the DragonBone sync timing. The previous PR only changed the event-driven synchronization mechanism to a per-frame polling synchronization mechanism.
Sorry about the issue, and the overall update experience.
To maintain and keep improve stability is indeed a very big challenge to our team.
Our team is also eager to hire more experienced and talented developers and architects. Unfortunately this is not a solvable problem by any individual.
Our effort to solve this problem is to add more robust CI processes to the workflow, you may notice that we already have a bunch of CI workflows like coding style check, compilation and build check, unit test etc. They were very helpful but not enough, the issue this topic mentioned, and most behavior or rendering issues can hardly be checked with the current CIs.
What about code review then, we do require all PRs to be reviewed before getting merged, the PR caused the issue also gets reviewed by two persons, unfortunately we haven’t notice the issue it potentially have, I believe deeper understanding of the system and experience help finding issues, but people are not perfect. So our next step is to introduce automatic PR test workflow, it will check real test cases on most important platforms including Windows, Mac, iOS, Android and Web, they will be all on real devices in our office. The process is now under testing, you can see it being tested in some of the PRs, like this one
I believe after it’s matured and being integrated as a required CI workflow, the quality of the engine will eventually have its guard. And I hope we will get less and less complains about regressions in the near future.
About iteration pace, we are also aware of the lacking of stable versions and feature versions are draining our resources. So we also decided that we will only have two major feature versions in 2023: which will be 3.8 in summer and 3.9 in winter.
Again, thanks for your contribution. Hope the explanation help the community to better understand our effort in quality improvement.
Thank you for the detailed response. This makes me much more confident for the future of Cocos and I’m very thankful to all the developers who are contributing to this project. Despite my occasional frustrations, Cocos has a lot of advantages compared to its competitors so I’d like to see it become even more successful.
