chore: switch to revanced library and bump patcher #1314
Conversation
Axelen123
added
the
ReVanced Manager Compose
|
Currently waiting on ReVanced/revanced-patches#2929 |
|
What is the reason for waiting? Compose is still a feature branch
|
|
Not to break patching in the mean time for the devs |
|
Compose manager is not a feature |
|
Currently it's not in main and dev branch, and is to be merged in dev as a feature branch. This PR has no reason to depend on patches. The development environment is to be responsible to handle the issue and mock the API |
|
Compose manager is a functional project just like flutter manager. Merging this would break it and there is no reason to do so until patches have updated. compose-dev not being merged to dev has nothing to do with this |
No, it is in a development branch. It does not matter if it's functional or not, PRs like this should not be blocked and instead, the development environment as previously suggested should cover your issue.
It does because compose-dev is considered a feature branch until merged to dev and then main. Until then the development environment is supposed to handle cases like pinning the patch version.
Development is being blocked unnecessarily and merge conflicts can arise if the PR is open long enough, which are both good reason to merge, regardless of the fact that the patches that manager has no relation with should not be a blocking reason to begin with in a developing environment. |
|
Compose manager does not belong here if it cannot operate as it used to before the migration. |
That does not change that it is not facing production and is in development. Again, the development environment has to cover your case, and not block this PR.
Because it is in production. There is no development environment in production like there has to be for compose. |
|
Compose manager is very close to release. I do not want a delayed patches release to delay a compose manager release. This is why I want the compose-dev branch to be compatible with main patches. |
This is fine, even if it were a day, the PR should not be blocked by patches.
But you are doing the opposite by blocking this PR, required for a release, due to patches release?
The compose dev branch will eventually be merged to the real dev branch and then to the main, at which point the patcher will have to be in sync for patches and manager. But currently you are delaying merging to compose-dev, far from production with reason that it would not be compatible with the currently released patches whereas:
|
|
This PR is not required for releasing compose manager unless patches require it. |
Yes because dev is gonna be merged to main, production, where the patcher version has to be synced when breaking changes are involved, whereas in this branch it does not as it is not gonna be merged to main after it reaches compose-dev. Once it is in dev, there we need to back off and sync.
Only user-facing manager is main. And until it reaches main, the development environment has to catch situations like this one. |
Syncing will take time if the other repositories suffer delays.
That does not change the nature of the project. Using newer versions of patcher makes sense for CLI because its more developer oriented, but manager is user-oriented. |
It does not face the user until its in main. Until its in main, the dev env has to be able to provide you with everything necessary to develop the app in its state. |
Managers API client currently always chooses non-dev releases. The releases endpoint does have an option to select dev releases, but implementing that is not within the scope of this PR. |
Yes, this is why I am saying that the dev env has to cover this and since it is out of scope of this PR this PR should not be blocked just because of that. |
|
The dev env currently does not cover the situation because of what I mentioned, so the PR is still blocked. |
|
In this case, if this PR is blocked by the dev env not supporting it, a PR should be made to allow that before merging this PR. |
|
Open an issue |
|
Moving to #1326 |
No description provided.