feat: A way to consume multiple releases/release descriptions

[Ushie]

Feature description

To display all the changelogs between the current version and new version, currently it only displays the latest version's description

Motivation

To allow users to know what is new between the version they're on and the latest version, they would be unaware of major changes if the major change was followed by a quick hotfix for example

Acknowledgements

• I have checked all open and closed feature requests and this is not a duplicate
• I have chosen an appropriate title.
• All requested information has been provided properly.

[oSumAtrIX]

ReVanced has no specific use case for "old" versions. This is not a concept we need because users should always use the latest version of patches. Similarly Google PlayStore for example only provides the latest versions of the apps. So this is a difficult request.

[Ushie]

How else can this be implemented to allow clients to display proper changelogs?

[oSumAtrIX]

I don't know, probably just the current changelogs of the release how else?

[Ushie]

@oSumAtrIX Any new ideas with a fresh mind?

[oSumAtrIX]

Unfortunately, past changelogs can't be shown without discussing a new contract between the patches project and the API. API could technically track and persist changelogs in a database, but this isn't quite elegant because it needs to copy them. With a contract, it could dynamically fetch the changelogs respectively, however for that the patches need to conform a specific requirement set by API and for that the contract would be needed.

[Ushie]

The issue with not being able to add changelogs to the API stems from a deeper problem — the /v4/manager endpoint is fundamentally flawed.

Right now, we have:

• /v4/manager
• /v4/manager/version

You’d expect /v4/manager to return general info about the manager, like a name, icon, and description — similar to the GitHub repo description. But instead, it returns the latest release info, and the “description” is actually a changelog, not a proper product description.

A more logical structure would be:

• /v4/manager → returns metadata about the manager (name, icon, description)
• /v4/manager/version → latest release version info
• /v4/manager/download → latest release download & changelog
• /v4/manager/changelogs → full list of changelogs, like /versions does for other data

The current structure seems to only make sense in the context of our website. But from an API perspective, it’s lacking — it exposes products but doesn’t actually describe them. Clients are forced to hardcode details that the API should provide, such as the name and potentially icon of ReVanced Manager

[oSumAtrIX]

Or just return all at /v4/manager. Your structure scales though if necessary, but as of now with the endpoints you mentioned, it is both faster at network layer due to making only one HTTP request for all data and easier to return everything at once. However the current structure does not prevent a /changelog endpoint in the first place. The real issue is different/what i explained in my previous comment.

[Ushie]

I don't understand why there would need to be a new contract, there's no need for API to do anything different than what it already does, listing changelogs works the same as listing versions, you only have to fetch the releases endpoint and you'll have the list of changelogs

[oSumAtrIX]

The contract would be needed because the only way API would not need to make a request everytime the range for the changelog is requested is by consuming the changelog md file from the repo. It could be an asset or directly from the source. Since patches repo arbitrarily decided to add the file, they can arbitrarily decide not to, thus breaking API unless API contracts with the patches repo to mandate the file's existence.

[Ushie]

In that case, how can we get started on creating that contract?

[oSumAtrIX]

It's not elegant to require patches repos to contract with API for this purpose. Patches would need to have this changelog file, changelogs wouldn't work with offline bundles and changelogs and patches would be two separate files just for the purpose of APIs requirements

[Aunali321]

Why can't the API just fetch the last N release descriptions from the GitHub API when needed? Caching could mitigate performance issues. The GitHub API provides the release body (changelog) for each tag.

1. The API periodically fetches the release notes (bodies) for the last N releases (e.g., 10-20, or all releases within the last year) directly from the GitHub API.
2. These could be cached within the revanced-api itself (e.g., in memory with a TTL, or a simple database/file cache).
3. Clients would request a version range, and the API would serve the relevant changelogs from its cache.

[oSumAtrIX]

Why can't the API just fetch the last N release descriptions from the GitHub API when needed?

Because it needs to contract with the backend to do so. GitHub may support it but other backends not. However that's not the issue. Patches already have a changelog file in the repo, but it's not mandatory, so API can contract with that without the need of the backend to list release changelogs.

1. Polling is not good. There's a gap between polls and it's inefficient
2. The cache is gonna be miss often because of the range. People update whenever so the range will be different. Instead, we can push forward the entire changelog of patches to the client. However, as it's arbitrary string, there's no way to cut off older changelogs.