[ ] 🧪 Tests: Adds new tests or modifies existing tests.
[x] 📝 Documentation: Updates or additions to documentation.
[x] 🗑️ Chore: Routine tasks, or maintenance.
[ ] ✅ Build configuration change: Changes to build or deploy processes.
Suggestions
I still highly suggest putting the library in maintenance mode, only accepting critical bug fixes to the master branch, and having a dev branch that accepts all kind of bug fixes and code quality improvements that have been explained, documented well, and possible to understand, carefully tested with different features, breaking changes will occur, will be only releasing those changes as pre-release. We don't want to worry too much about introducing breaking changes as it's not our first priority at the moment, and we don't want to keep releasing major versions one after the other only to fix some design issues by introducing a breaking change. We already made some breaking changes in the past.
This dev branch will be released as pre-release for a long time, new features will not be added especially if not clear, and bug fixes should be manually tested (I prefer if we write unit, widget, and maybe integration tests for them but will not happen anytime soon).
Why is this necessary?
What we're doing at the moment is that we fix a issue, see if the issue was fixed, submit a PR, and then merge it, once we discover the other 15 issues, we will revert it or deprecate the change. We should be more cautious about introducing new changes, new changes should be at least understood by one maintainer to ensure it's possible to understand, well documented, and doesn't have quality issues.
Having a variable called `_restoreToolbar` to fix a magnifier bug to a file (that has over 1500 lines of code) with different variables, classes, and things is not ideal, and requires contacting the contributor to understand the details after the changes have been merged. Doesn't matter what kind of knowledge or experience you have, you will never able to understand those changes without introducing more issues (in best cases). Which is why more maintainers and contributors are leaving the project, one of the main reasons why I left previously.
I have introduced issues myself, especially in 2023 but I have fixed almost most of them and still working on fixing more issues. I have tested my recent change #2230 very well and I still find bug fixes and design issues, which is why it's not up for merge yet I'm still thinking about having integration tests and it's still not qualified enough. @AtlasAutocode and @CatHood0 are even more cautious and introduce much fewer issues.
I'm saying all of this because I want all maintainers, contributors, and users to take the issues we have more seriously. At least most of them.
Description
Add an important note for contributors before introducing new features.
Related Issues
We don't have any specific issue or discussion that's related at the moment but a discussion was made in unrelated issue #2235
Once we have a separate issue, this PR will be updated.
Type of Change
Suggestions
I still highly suggest putting the library in maintenance mode, only accepting critical bug fixes to the
masterbranch, and having adevbranch that accepts all kind of bug fixes and code quality improvements that have been explained, documented well, and possible to understand, carefully tested with different features, breaking changes will occur, will be only releasing those changes as pre-release. We don't want to worry too much about introducing breaking changes as it's not our first priority at the moment, and we don't want to keep releasing major versions one after the other only to fix some design issues by introducing a breaking change. We already made some breaking changes in the past.This dev branch will be released as pre-release for a long time, new features will not be added especially if not clear, and bug fixes should be manually tested (I prefer if we write unit, widget, and maybe integration tests for them but will not happen anytime soon).
Why is this necessary?
What we're doing at the moment is that we fix a issue, see if the issue was fixed, submit a PR, and then merge it, once we discover the other 15 issues, we will revert it or deprecate the change. We should be more cautious about introducing new changes, new changes should be at least understood by one maintainer to ensure it's possible to understand, well documented, and doesn't have quality issues. Having a variable called `_restoreToolbar` to fix a magnifier bug to a file (that has over 1500 lines of code) with different variables, classes, and things is not ideal, and requires contacting the contributor to understand the details after the changes have been merged. Doesn't matter what kind of knowledge or experience you have, you will never able to understand those changes without introducing more issues (in best cases). Which is why more maintainers and contributors are leaving the project, one of the main reasons why I left previously. I have introduced issues myself, especially in 2023 but I have fixed almost most of them and still working on fixing more issues. I have tested my recent change #2230 very well and I still find bug fixes and design issues, which is why it's not up for merge yet I'm still thinking about having integration tests and it's still not qualified enough. @AtlasAutocode and @CatHood0 are even more cautious and introduce much fewer issues. I'm saying all of this because I want all maintainers, contributors, and users to take the issues we have more seriously. At least most of them.