ReVanced
feat: Add an option to view patches changelog
Feature description
There's currently no way for an user to know what changed between each patches version without a changelog in the manager.
Motivation
It was present in flutter manager and should be ported over to compose as well.
Acknowledgements
- [x] I have checked all open and closed feature requests and this is not a duplicate.
- [x] I have chosen an appropriate title.
- [x] The feature request is only related to ReVanced Manager.
Even if this is implemented, it would only show the latest changelog
Imagine this:
v12.0.1
fix: small bug
v12.0.0
12000 lines of huge major important changes
ReVanced Manager would only be able to show v12.0.1, due to the ReVanced API not providing any options for previous changelogs @oSumAtrIX Is it about time we revisit this issue?
It is not possible to display changelogs over multiple versions properly. API is technically just a "static" transformer. The backend is abstracted in a way where each release has a description (note how description != changelog). This is intentionally designed to generalize usage. GitHub and changelogs are one abstract use case, but all you need is technically the release details, like the file and description and implement the backend interface for it.
To realize changelogs over multiple releases, api wouild have to implement "additional" abstract logic which breaks generalization, since now we force the concept changelogs over descriptions as well as the non 1:1 logic between backend and api of reading and parsing multiple releases at once.
This is an architectural issue. Backends don't provide a "changelog" endpoint, nor is it general enough for a backend. A changelog endpoint would require scraping the backend of some sort if the backend does not support changelogs which is the case for most common backends, github, gitlab, file systems etc, they dont have this kind of logic. (which means dynamic API queries and lots of caching and combinations of ranges and whatnot)
Yes, it is possible to implement, but no, its not good. Closing until good suggestions are given to work in this situation
One dirty solution would be to ask the backend for an optional changelog so it can be mirrored. E.g.
/patches/changelog
No syntax specification, or ranges, just one big changelog file, up to the backend to design. Apps like manager can parse as markdown by default, or do their processing on their own behalf (like truncating, ranges etc)
@Ushie I think this is an okay solution, please move this to the respective api issues