Create a auto-updating page of versions to be used

[SodaWithoutSparkles]

Motivations

This can help users to find versions to be used w/o digging in the patches README

Solutions

• parse API for all pkgName
• for each pkgName, extract "latest supported version (LSV)"
• LSV is defined as the latest version that is compatible with all patches targeting pkgName

Approach

Use GH actions to run a bash script for that does the Solution part. The script should be ran periodically and manually. A "last update" timestamp should be added. The timestamp should also be updated at least each week, to ensure that the script is still "alive"

Related

I have done this for youtube already. The following GH action config and bash script can be used as a starting ground.

• GH action config

• script

@alexandreteles @HokoraYinphineMPP

[alexandreteles]

Seems like a good idea. We need the website people to look into how that would affect their dealings with the documentation. @xafn and @Axelen123 should have input to give on this topic.

[SodaWithoutSparkles]

There should also be a common name lookup table. The LUT should convert pkgName to human-readable common name.

Example: com.android.google.youtube to YouTube

[SodaWithoutSparkles]

Created a gist as example: https://gist.github.com/SodaWithoutSparkles/a526189a25221b1a5ff0e1cd8957c716

Generated by a python script, should be compatible w/ gh actions

[oSumAtrIX]

The documentation should be agnostic to any patch. The version of the patches should be "figured out" differently. For example, ReVanced CLI can parse and display it, or ReVanced Manager, or the API can be used to display it on the website, and so on, but the docs isn't the place for this.

[SodaWithoutSparkles]

The documentation should be agnostic to any patch. The version of the patches should be "figured out" differently. For example, ReVanced CLI can parse and display it, or ReVanced Manager, or the API can be used to display it on the website, and so on, but the docs isn't the place for this.

The approach is agnostic to any patch. If the API updated, the list would also update too. Ain't we gonna complete the official guide on how to use CLI to patch? This should be a part of the official guide.

How is the CLI gonna provide the version required? CLI currently dont have any input of the package name besides the apk, and unless the user ran the command once, he cannot know the version to be used.

[oSumAtrIX]

The approach is agnostic to any patch.

No, because the docs now include a reference to some patches.

Ain't we gonna complete the official guide on how to use CLI to patch?

I don't know what you mean by that, CLI docs are merged and available on main.

How is the CLI gonna provide the version required

Using the --list option with --with-versions.

[SodaWithoutSparkles]

No, because the docs now include a reference to some patches.

Where is the reference to "some patches"? I indeed can't find them.

I don't know what you mean by that, CLI docs are merged and available on main.

Do you mean this? It is nowhere enough. We can't assume all users of CLI magically have the correct java version installed, especially when Windows doesn't ship w/ the correct version.

If you mean this, the version is super outdated. We should concentrate all documentation and build instructions to a single place.

Using the --list option with --with-versions.

Not according to the usage docs: https://github.com/revanced/revanced-cli/blob/main/docs/1_usage.md

---

Edit: the symbolic link does not even link to the correct place

[oSumAtrIX]

Where is the reference to "some patches"? I indeed can't find them.

There is none because the docs are agnostic to any patch. I am referring to your suggestion which would make them appear.

Do you mean this?

No, I am referring to the docs here.

We can't assume all users of CLI magically have the correct java version installed,

That's why it is mentioned here.

especially when Windows doesn't ship w/ the correct version

Windows doesn't ship with any Java version, not just the incorrect one. And the operating system is not a question at all.

If you mean this, the version is super outdated

I don't know what you mean by outdated. The version is what is being used to use ReVanceed CLI.

Not according to the usage docs: revanced/revanced-cli@main/docs/1_usage.md

The option -l is the short option name for --list.

[SodaWithoutSparkles]

There is none because the docs are agnostic to any patch. I am referring to your suggestion which would make them appear.

I am confused here, in the example provided, there is 0 mention of any patch.

No, I am referring to the docs here.

It is still nowhere enough, because, as said, we can't assume all users of CLI magically have the correct Java version installed,

That's why it is mentioned here.

The problem is not all users know how to get Zulu openjdk17. They can't even use the manager properly. We need the CLI for armv7 and etc. The fact that the user needs to get 3 files (patches, integrations, youtube apk) besides the CLI is very confusing to a lot of users

Windows doesn't ship with any Java version, not just the incorrect one. And the operating system is not a question at all.

I think Windows has 32-bit Java by default. At least this is the case for all users I have encountered. java version "1.8.0_271"

I don't know what you mean by outdated. The version is what is being used to use ReVanceed CLI.

Look at the YouTube version recommended. This shows that the docs are poorly maintained and/or not updated regularly.

The option -l is the short option name for --list.

Does the guide said to use --with-versions?

If we are going to phase out community-driven guides or not link to them entirely, we need to at least have some sort of guide targeting non-developers.

[oSumAtrIX]

The problem is not all users know how to get Zulu openjdk17. They can't even use the manager properly

The docs are not meant to be a tutorial on how to install Java. If you do not know that, you can't proceed using ReVanced CLI.

The fact that the user needs to get 3 files (patches, integrations, youtube apk) besides the CLI is very confusing to a lot of users

Thats the minimum requirement to be able to use ReVanced CLI. You need patches, optionally integrations and the APK.

I am confused here, in the example provided, there is 0 mention of any patch.

You have sent a gist that mentions around 30.

It is still nowhere enough, because, as said, we can't assume all users of CLI magically have the correct Java version installed,

If they don't have it installed, the prerequisite says to have it.

I think Windows has 32-bit Java by default. At least, this is the case for all users I have encountered.

No, Windows does not ship Java, and even if it would, it doesn't change that the docs mention the version you need.

Does the guide said to use --with-versions?

No, but this issue isn't discussing this anyways

If we are going to phase out community-driven guides or not link to them entirely, we need to at least have some sort of guide targeting non-developers

ReVanced CLI is not targeting the average user. For that, ReVanced Manager is present. ReVanced CLI is less user-friendly by nature. Despite that, any docs should be agnostic to any patch because that is by nature of ReVanced. Including the versions inside the docs would break that.

[oSumAtrIX]

If you want versions for patches to be present anywhere, it should be in the respective patches repository.

[SodaWithoutSparkles]

Understandable. Will move to patches repo and incorporate it into existing README as suggested tmr.

[Axelen123]

The website has information about patches. https://dev.revanced.app/patches

It uses package names, but still