Open SbloodyS opened 1 month ago
+1
+1
+1, and because of this issue try to remove an existing plugin for our product, and as I remember we do not remove anyone before. can we add some docs and guide someone who wants to remove other plugins? Such as we have to discuss in issue or mail thread, or we only remove plugin in major or minor version?
+1, and because of this issue try to remove an existing plugin for our product, and as I remember we do not remove anyone before. can we add some docs and guide someone who wants to remove other plugins? Such as we have to discuss in issue or mail thread, or we only remove plugin in major or minor version?
I think we should remove plugin only in major version.
+1, and because of this issue try to remove an existing plugin for our product, and as I remember we do not remove anyone before. can we add some docs and guide someone who wants to remove other plugins? Such as we have to discuss in issue or mail thread, or we only remove plugin in major or minor version?
I think we should remove plugin only in major version.
Agree with that, and we can add some deprecated notice for those task we remove in dev branch but still not released, WDYT
Agree with that, and we can add some deprecated notice for those task we remove in dev branch but still not released, WDYT
Yes, we've already add it to the docs in https://github.com/apache/dolphinscheduler/blob/dev/docs/docs/en/guide/upgrade/incompatible.md
+1
@SbloodyS Hi SbloodyS. Can I understand that if a feature is found to have some bugs and has few users, then it can be removed?
@SbloodyS Hi SbloodyS. Can I understand that if a feature is found to have some bugs and has few users, then it can be removed?
I think no PMC/Committer is willing to continue to maintain, and at the same time, there are bugs that are not fixed and rarely used. Then we will remove it. The situation is similar to that of #16093.
That means if someone is willing to fix these bugs and the fixes pass verification, then the feature can be retained and not removed.
That means if someone is willing to fix these bugs and the fixes pass verification, then the feature can be retained and not removed.
Yes.
I will look for someone in the community who is willing to fix these bugs.
Search before asking
Motivation
The dynamic task type is currently supported in a user-configured manner. The user executes a while like loop to determine the exit condition. After the exit, specify multiple times of sub-workflows based on exit conditions.
The current task type has a lot of bugs, and I think the operation of executing multiple times of sub-workflows is not universal, and it is too customized for a certain business scenario. And at the same time, I search in the issue list found that only a single digit of users were using it.
So I suggest remove this dynamic task type.
Design Detail
No response
Compatibility, Deprecation, and Migration Plan
No response
Test Plan
No response
Code of Conduct