Allow passing in package name suffix through CLI

[XiangRongLin]

Checklist

• I checked, but didn't find any duplicates (open OR closed) of this issue in the repo.
• I have read the contribution guidelines given at https://github.com/TeamNewPipe/NewPipe/blob/HEAD/.github/CONTRIBUTING.md.
• This issue contains only one feature request. I will open one issue for every feature I want to request.

Describe the feature you want

• Allow specifying an optional package name suffix when calling ./gradlew assembleRelease --stacktrace
• Similiar to how debug build have different package names

Is your feature request related to a problem? Please describe it

• My nightly builds have the same package name, so you can't install both versions
• [Feature Request] Different package names for nightly builds XiangRongLin/NewPipe-nightly#1

Additional context

How will you/everyone benefit from this feature?

• Installation of both versions is possible

[XiangRongLin]

@TobiGr Anything against this?

[XiangRongLin]

@Stypox maybe you can add some opinion on this, since TobiGr is not answering? I don't want to start working to only have it rejected later on

[Stypox]

I don't see why not, it would just be a useful addition. Just make sure to document it well.

[TobiGr]

Sorry, I missed this ticket.
That sounds useful.
While you are at it, please also document the parameter added in #6858

[XiangRongLin]

How and where do you want to have it documented.

As for skipFormatKtLint I find the name very telling of what it is. The documentation i would do is "Skips the formatKtLint step" which is useless.

[Stypox]

The documentation is more about "know that this is there", obviously its meaning is obvious

[opusforlife2]

As a rookie, I can tell you that when you see a method name like that which is fairly obvious but not commented, I would naturally see the obvious meaning, but then I would second-guess myself, "Is that really what it means? Maybe it's not actually that simple." and then check the related code anyway to confirm it.

A simple one line comment would help avoid that uncertainty.

[XiangRongLin]

The documentation is more about "know that this is there", obviously its meaning is obvious

Then again where should it be? There is currently is no documentation about all the custom gradle task like formatKtlint, runCheckstyle or runKtlint to which skipFormatKtlint could be added.

---

A simple one line comment would help avoid that uncertainty.

Where would that one line comment be then?

1. If it's at the call site in the ci.yml, what should be done if there are other call sites, copy it over?
2. If it's at the usage site inside the build.gradle then the comment is just duplicating the code

[opusforlife2]

I would go for 2, even if it duplicates the code. If a function isn't used immediately or very close by, then there should be a comment which prevents the user from going and looking for the usages.

Edit: At least, that's been my experience with navigating Newpipe's code with Ctrl+B in Android Studio and finding out that I'm completely lost.