App changelog
155 |
156 | INSERT_COPIED_CHANGELOG_HERE
157 |
158 | ```
159 | - Once you have created the issue, pin it using the "Pin issue" button on the right
160 | - Update the `ISSUE_NUMBER` in the pull request description
161 | - *Check out [#8230](https://github.com/TeamNewPipe/NewPipe/issues/8230) for reference*
162 |
163 | ## Testing APKs
164 |
165 | The first time you open the release issue, and then each time some changes are made to the release PR, you should provide a debug APK in the `## Testing for regressions` section.
166 |
167 | - Wait for the Continuous Integration (CI) to finish testing the PR, then download the resulting debug APK artifact from the "Checks" tab
168 | - Rename it to `NewPipe_vX.X.X_RC1_debug.apk` where `RC1` should be incremented to `RC2` and so on each time a new APK is provided
169 | - Zip it and make sure the `.zip` file has the same name as the `.apk` it contains
170 | - Upload it in the issue description, replacing the `...` placeholder used above
171 |
172 | Sometimes it might be needed to also provide a release APK. In this case follow the same steps as above, with these differences:
173 |
174 | - Make sure you are on the `release-X.X.X` branch
175 | - Build the **release** APK yourself in Android Studio and sign it with your keys
176 | - *Temporarily* edit the `app/build.gradle` file and add `System.properties.put("packageSuffix", "vX_X_X")` at the top of the `android -> buildTypes -> release` block, which ensures that the application has a different package name than the official one
177 | - Build and sign an APK via "Build -> Generate Signed Bundle / APK..."
178 | - Make sure it installs correctly on your device
179 | - Use this naming scheme: `NewPipe_vX.X.X_RC1_release.apk`
180 | - Add a line to the `## Testing for regressions` section, of this form: `Release APK (built and signed by @YOUR_GITHUB_USERNAME): ...`
181 |
182 | ## Taking care of regressions (quickfixes)
183 |
184 | The release issue and pull request should stay open for **roughly one week**, so that people can test the provided APKs and give feedback. If a *regression* is reported by some user, it should possibly be solved before releasing, otherwise the app would become more broken after each release. A *regression* is a bug now present in some code that used to run well in the last release, but was then modified in this release (supposedly to fix something else) and is now broken. So the following do not classify as regressions: some videos stop working because YouTube made some changes; the newly introduced big feature XYZ is still not perfect and has some bugs; a random crash reproducible also on previous versions... You get the point. Before releasing, try to fix any regressions that are reported, but avoid fixing non-regressions, since those should be treated with the same care and attention as all other issues. As a Release Manager, you might be required to fix regressions, so plan your release at a time when you are available.
185 |
186 | Pull requests fixing regressions should target the `release-X.X.X` branch, not the `dev` branch! When merging those PRs, also provide a new Release Candidate APK.
187 |
188 | ## Finally merging the pull request
189 |
190 | Once enough time has passed and all regressions and TODOs have been solved, you can proceed with the actual release. The following points include merging weblate changes again.
191 |
192 | - In the local repository, check out the release branch and make sure it is up-to-date with the remote
193 | - `git checkout release-X.X.X`
194 | - `git pull origin release-X.X.X`
195 | - Go to [Weblate's Maintenance tab](https://hosted.weblate.org/projects/newpipe/#repository)
196 | - Press *Lock*; remember to *Unlock* later!
197 | - Press *Update*
198 | - Press *Commit*, if needed
199 | - Now go back to the local git repository
200 | - Delete the `weblate-dev` branch, just in case
201 | - `git branch -D weblate-dev`
202 | - Fetch changes from Weblate (in particular you should see the `weblate/dev` remote branch being updated)
203 | - `git fetch weblate`
204 | - Obtain the hash of the last commit on the `weblate/dev` remote branch
205 | - `git log -n 1 --pretty="format:%H" weblate/dev`
206 | - Cherry pick the hash you obtained above into the release branch (the one you are currently on)
207 | - `git cherry-pick HASH`
208 | - Push the changes to the remote branch
209 | - `git push origin release-X.X.X`
210 | - Merge the PR you created before
211 | - Delete the GitHub remote branch associated with the PR, i.e. `release-X.X.X` (there should be a button in the PR)
212 | - Close the issue you created before
213 | - Merge `dev` back into `master` (since the PR merged changes onto `master`)
214 | - `git checkout master`
215 | - `git pull origin master`
216 | - `git checkout dev`
217 | - `git pull origin dev`
218 | - `git merge master`
219 | - `git push origin dev` or create another temporary PR and merge it immediately
220 | - Go to [Weblate's Maintenance tab](https://hosted.weblate.org/projects/newpipe/#repository)
221 | - **Press *Unlock***
222 |
223 | ## Creating the APK
224 |
225 | Now on the remote `master` branch there is the release code which you need to turn into an APK. The APK needs to be built with **JDK 21**, [as agreed with the F-Droid team](https://github.com/TeamNewPipe/NewPipe/issues/11754), to ensure reproducibility.
226 |
227 | You should build the APK using the `build-release-apk` CI workflow:
228 |
229 | - Go to the [workflow's page](https://github.com/TeamNewPipe/NewPipe/actions/workflows/build-release-apk.yml)
230 | - The page will say "This workflow has a `workflow_dispatch` event trigger.", click on "Run workflow" on the right
231 | - In the "Use workflow from" prompt, don't change anything (i.e. use `dev`); the workflow uses the last commit from the `master` branch in any case!
232 | - Wait for the workflow to finish
233 | - Download `app.zip` from the workflow artifacts, extract the APK from the archive, and make sure it is called `NewPipe_vX.X.X.apk`
234 |
235 | *In alternative*, in case something is wrong with the CI or you don't have permission to run the workflow, follow these steps to build with Android Studio:
236 |
237 | - In the local repository, check out the `master` branch and make sure it is up-to-date with the remote
238 | - `git checkout master`
239 | - `git pull origin master`
240 | - Open the local project in Android Studio
241 | - Go to *Settings -> Build, Execution, Deployment -> Build Tools -> Gradle -> Gradle JDK* and select JDK 21
242 | - Run the Gradle `clean` task using Android Studio's interface, in order to clean up temporary/cache files that may interfere with reproducible builds
243 | - Double press Ctrl, type `gradle clean`, press Enter
244 | - Make sure leftover files from building RC releases are actually removed, in order to avoid confusion
245 | - `rm -rf ./app/release`
246 | - Run the Gradle `assembleRelease` task using Android Studio's interface: it will start the process of building an unsigned APK
247 | - Double press Ctrl, type `gradle assembleRelease`, press Enter
248 | - After a while you should find the APK under `./app/build/outputs/apk/release/app-release-unsigned.apk`
249 | - Rename `app-release-unsigned.apk` to `NewPipe_vX.X.X.apk`
250 |
251 | ## Having the APK signed by @TheAssassin
252 |
253 | Currently @TheAssassin is the only holder of NewPipe's APK signing keys. Therefore you should send the unsigned APK to him, after which he will sign it and send it back to you. He will also then publish the signed APK in NewPipe's F-Droid repo.
254 |
255 | - Make sure the APK is called `NewPipe_vX.X.X.apk`
256 | - Generate a signature for the APK file
257 | - `gpg -b NewPipe_vX.X.X.apk` will generate `NewPipe_vX.X.X.apk.sig`
258 | - It will also output 'using "FINGERPRINT" as default secret key for signing'; keep track of the `FINGERPRINT` part
259 | - Send an email to @TheAssassin and attach both `NewPipe_vX.X.X.apk` and `NewPipe_vX.X.X.apk.sig`
260 | - If @TheAssassin does not already know it, send him your PGP key `FINGERPRINT` you obtained before
261 | - You should not send it using email this time, but using another service through which @TheAssassin can be almost sure it is really you (this is a sort of 2FA)
262 | - For example, you can send it on the IRC group, or create a GitHub gist with the fingerprint and then give that link to @TheAssassin
263 | - Notify him on IRC that you have sent him an email
264 | - He will send you back the signed APK
265 | - Make sure its name is still `NewPipe_vX.X.X.apk` (rename if it's not the case)
266 | - Install it on your device to see if everything went well (note that installation will work only if your currently installed version of newpipe comes from NewPipe's F-Droid repo or GitHub)
267 | - **Tell @TheAssassin to "push the buttons"**, i.e. publish the signed APK in NewPipe's F-Droid repo.
268 |
269 | ## Publishing the release
270 |
271 | - Go to the draft changelog [kept on GitHub](https://github.com/TeamNewPipe/NewPipe/releases)
272 | - Set `vX.X.X` as the tag name
273 | - Set `vX.X.X` as the release title
274 | - Set `master` as the "Target:" branch
275 | - Attach the signed APK @TheAssassin sent you
276 | - Publish the release
277 | - Profit :-D
278 |
279 | ## Updating the official F-Droid repository
280 |
281 | - You should open a Merge Request similar to [this one](https://gitlab.com/fdroid/fdroiddata/-/merge_requests/15367) on the [fdroiddata](https://gitlab.com/fdroid/fdroiddata) repository
282 | - Follow [these instructions](https://f-droid.org/en/docs/Reproducible_Builds/#publish-both-upstream-developer-signed-and-f-droid-signed-apks) to extract signatures from the APK
283 | - This step is not mandatory, as the F-Droid team will take care when they notice the new release, but it is better if we do not burden them with more work
284 |
285 | ## Blog post
286 |
287 | The blog post writers need an up-to-date list of merged PRs numbered in chronological order. This is so that they can keep track of what changes have already been detailed in the draft blog post, and which ones still need to be added. So make sure that there is always at least one up-to-date "master copy" of the draft release notes available for them to review.
288 |
289 | The blog post should ideally be published before the GitHub release is made (so that the link to it works!), but in case of some delay, it is fine to let the blog post come later. It is far more important to get the release into users' hands sooner.
290 |
291 | - In order for the blog post to be published, ask @TheAssassin to "press the buttons" again
292 | - Once the blog post is ready, add this block of text on top of the release notes on GitHub:
293 | ```
294 | [:arrow_right: :arrow_right: :arrow_right: Read the blog post :arrow_left: :arrow_left: :arrow_left:](LINK_TO_BLOG_POST)
295 | ```
296 |
--------------------------------------------------------------------------------
/docs/08_documentation.md:
--------------------------------------------------------------------------------
1 | # About This Documentation
2 |
3 |
4 | The documentation you are currently reading was written using [mkdocs](https://www.mkdocs.org/). It is a tool that will generate a static website based on [markdown](https://www.markdownguide.org/) files. Markdown has the advantage that it is simple to read and write, and that there are several tools that can translate a markdown file into languages like HTML or LaTeX.
5 |
6 | ## Installation
7 |
8 | Mkdocs is written in [Python](https://www.python.org/) and is distributed through the Python internal package manager [pip](https://pypi.org/project/pip/), thus you need to get python and pip running on your operating system first.
9 |
10 | ## Windows
11 |
12 | 1. Download the latest [Python3](https://www.python.org/downloads/windows/) version.
13 | 2. When running the setup program, make sure to tick, "Add Python 3.x to PATH".
14 | 
15 | 3. Install Python.
16 | 4. Open PowerShell or cmd.exe and type: `pip3 install mkdocs`.
17 |
18 | ## MacOS
19 |
20 | MacOS already includes Python, however, pip is still missing. The easiest and most nondestructive way is to install the MacOS package manager, [homebrew](https://brew.sh/index_de), first. The advantage of homebrew is that it will only modify your home directory, and not the root dir, so your OS will not be tampered with.
21 |
22 | 1. Install [homebrew](https://brew.sh/index_de).
23 | 2. Install Python from Homebrew, which will also install pip. Enter this command:
24 | `brew install python`.
25 | 3. Install mkdocs:
26 | `pip3 install mkdocs`.
27 |
28 | ## Linux/*BSD
29 |
30 | Linux/*BSD also has Python pre-installed. Most distributions also contain pip by default. If it is not installed, you may need to figure out how to install pip3 through the package manager of your system.
31 |
32 | 1. Install pip3 with these commands according to distributions:
33 | - __Ubuntu/Mint__: `apt install python3-pip`
34 | - __Fedora/CentOS__: `sudo dnf install python3-pip`
35 | - __Arch/Manjaro__: `sudo pacman -S python-pip`
36 | - __openSuse__: `sudo zypper install python-pip`
37 | - __*BSD__: You are already advanced enough to know how you can force the bits on your disk to become pip by meditating upon it.
38 | 2. Run `pip3 install mkdocs` to install mkdocs only for the current user,
39 | or run `sudo pip3 install mkdocs` to install mkdocs systemwide. Last one has the higher chance to work properly.
40 |
41 | ## Android/ChromeOS
42 | This might sound funny, but according to the growing amount of Chromebooks and Android tablets with keyboards, this might actually be useful.
43 |
44 | 1. Install the [Termux App](https://termux.com/) from [F-Droid](https://f-droid.org/packages/com.termux/).
45 | 2. Launch Termux and type `apt update`
46 | 3. Install Python and Git with the command: `apt install git python`
47 | 4. Install mkdocs with `pip install mkdocs`.
48 |
49 | From herein, everything will be the same as on Desktop. If you want to edit the files, you can (besides vim or emacs which are available through Termux) use your preferred text editor on Android. This is possible by opening the files with the Termux integration of the build in android file manager:
50 |
51 | 
52 |
53 | ## Updating
54 | Sometimes, mkdocs changes the way of how it serves, or the syntax will differ. This is why you should make sure to always run the latest version of mkdocs. To check, simply run `pip3 install --upgrade mkdocs` or `sudo pip3 install --upgrade mkdocs` if you installed pip system wide on a Linux/BSD* system.
55 |
56 | ## Using mkdocs
57 | In order to extend this documentation, you have to clone it from its [GitHub repository](https://github.com/TeamNewPipe/documentation). When you clone it, you will find a [mkdocs.yml](https://github.com/TeamNewPipe/documentation/blob/master/mkdocs.yml) file, and a [docs](https://github.com/TeamNewPipe/documentation/tree/master/docs) directory inside. The yaml file is the [config file](https://www.mkdocs.org/user-guide/configuration/) while in the directory docs the documentation files are stored. [Here](https://www.mkdocs.org/user-guide/writing-your-docs/) is a guide about how to use mkdocs.
58 |
59 | ## Write and Deploy
60 | If you are writing a documentation page and want a live preview of it, you can enter the root directory of this documentation project, and then run `mkdocs serve` this will start the mkdocs internal web server on port `8000`. So all you have to do is type `localhost:8000` into the address bar of your browser, and here you go. If you modify a file, and save it, mkdocs will reload the page and show you the new content.
61 |
62 | If you want to deploy the page so it will be up to date at the [GitHub pages](https://teamnewpipe.github.io/documentation/), simply type `mkdocs gh-deploy`. However, please be aware that this will not push your changes to the `master` branch of the repository. So, you still have to commit and push your changes to the actual git repository of this documentation. _Please be aware that only privileged maintainers can do this._
63 |
--------------------------------------------------------------------------------
/docs/09_maintainers_view.md:
--------------------------------------------------------------------------------
1 | # Maintainers' Section
2 |
3 | These are some basic principles that we want maintainers to follow when maintaining NewPipe.
4 |
5 |
6 | ### Keep it Streamlined
7 | NewPipe is a media player for devices on the Android platform, thus it is intended to be used for entertainment. This means it does not have to be some professional
8 | application, and it does not have to be complicated to be used.
9 | However NewPipe might not focus on the casual user completely as there are
10 | some features designed for more experienced users which may require some knowledge about
11 | code, however in essence NewPipe should be easy to use, even for an average Android user.
12 |
13 | 1. __Don't add too many special
14 | features.__ NewPipe does not have to be an airplane cockpit. Do not try to fill every single niche that might exist. If people wanted more advanced features, they
15 | would use professional tools. If you add too much functionality, you add complexity, and complexity scares away the average user. Focus on NewPipe's scope as a **media player** for the end user, and only as such.
16 | 2. __Usability of the user interface should be prioritized.__ Try to make it comply with
17 | [material design guidelines](https://material.io/design/guidelines-overview/).
18 |
19 |
20 | ### Bugfixes
21 |
22 | ]
23 |
24 | *Disclaimer: This is a meme. Please don't take it personally.*
25 |
26 | __Always prioritize fixing bugs__, as the best application with the best features
27 | does not help much if it is broken, or annoying to use. Now if a program
28 | is in an early stage it is quite understandable that many things break. This
29 | is one reason why NewPipe still has no "1" in the beginning of its version
30 | number.
31 | By now, NewPipe is in a stage where there should be a strong focus on
32 | stability.
33 |
34 | 1. If there are multiple Pull Requests open, check the ones with bugfixes first.
35 | 2. Do not add too many features every version, as every feature will inevitably
36 | introduce more bugs. It is OK if PRs remain open for a while, but don't leave them open for too long.
37 | 3. If there are bugs that are stale, or open for a while bump them from time
38 | to time, so devs know that there is still something left to fix.
39 | 4. Never merge PRs with known issues. From our perception the community does not like to fix bugs, this is why you as a maintainer should
40 | especially focus on pursuing bugs.
41 |
42 |
43 | ### Features
44 |
45 | Features are also something that can cause a headache. You should not blindly
46 | say yes to features, even if they are small, but you should also not immediately say no. If you are not sure, try the feature, look into the
47 | code, speak with the developer, and then make a decision. When considering a feature, ask yourself the following questions:
48 |
49 | - Was the feature requested by only a few, or by many?
50 | - Avoid introducing niche features to satisfy a small handful of users.
51 | - Was the code rushed and messy, and could a cleaner solution be made?
52 | - A pull request that adds a frequently requested feature could implement the feature in a messy way. Such PRs should not be merged as it will likely cause problems later down the line, either through problems of extending the feature by introducing many bugs, or simply by breaking the architecture or the philosophy of NewPipe.
53 | - Does the amount of code justify the feature's purpose?
54 | - Use critical thinking when considering new features and question
55 | whether that features makes sense, is useful, and if it would benefit NewPipe's users.
56 |
57 |
58 |
59 | ### Pull Requests
60 |
61 | If a PR contains more than one feature/bugfix, be cautious. The more stuff a PR changes, the longer it will take to be added.
62 | There also might be things that seem to not have any issues, but other things will, and this would prevent you from merging a PR. This is why it is encouraged to keep one change per pull request, and you should insist that contributors divide such PRs into multiple smaller PRs when possible.
63 |
64 | ### Community
65 |
66 | When you talk to the community, stay friendly and respectful with good etiquette.
67 | When you have a bad day, just don't go to GitHub (advice from our experience ;D ).
68 |
69 | ### Managing translations via Weblate
70 | NewPipe is translated via [Weblate](https://hosted.weblate.org/projects/newpipe).
71 | There are two different components which are open for translation:
72 |
73 | - The app [`strings`](https://hosted.weblate.org/projects/newpipe/strings/).
74 | - The fastlane [metadata](https://hosted.weblate.org/projects/newpipe/metadata/);
75 | this includes the F-Droid store description and changelogs.
76 |
77 | Maintainers can access more options to handle Weblate via the
78 | [Manage > Repository Maintenance](https://hosted.weblate.org/projects/newpipe/#repository) button
79 | or via the [Weblate CLI](https://docs.weblate.org/en/latest/wlc.html#wlc). These options include
80 | basic access to Git operations like commit and rebase
81 | as well as locking Weblate to prevent further changes to translations.
82 |
83 | [](https://hosted.weblate.org/projects/newpipe/#repository)
84 | `HINT: When updating Weblate via the web interface, please use the "Update > Rebase" option.`
85 |
86 | #### Update Weblate
87 |
88 | Weblate is based on NewPipe's `dev` branch and is configured to automatically update its repository to be in sync with NewPipe.
89 | However, Weblate does not update its branch often, therefore it is better to update it manually after changing strings in NewPipe.
90 |
91 | To do thus manually, commit the Weblate changes and rebase the repository.
92 | Sometimes conflicts need to be resoled while rebasing the repository.
93 | Conflicts need to be addressed ASAP, because Weblate is automatically locked once conflicts occur.
94 | To do so, [merge the changes from Weblate into NewPipe](#merge-changes-from-weblate-into-newpipe).
95 | If Weblate does not recognize the new commit by itself, ask Weblate to rebase once more.
96 | Weblate unlocks the translations when all conflicts are resolved and no errors are detected.
97 |
98 | #### Merge changes from Weblate into NewPipe
99 | Weblate does not push the translation changes to NewPipe automatically.
100 | Doing this manually, allows the maintainers to do a quick review of the changes.
101 |
102 | Before merging weblate changes into NewPipe, make sure to commit all Weblate changes and
103 | lock the Weblate to prevent modifications while you update Weblate.
104 | To merge the changes into NewPipe, checkout Weblate's `dev` branch.
105 | You have read access to Weblate's repository via `https://hosted.weblate.org/git/newpipe/strings/`.
106 | If there are conflicts when rebasing weblate, resolve them.
107 |
108 | Check the following things:
109 | - Is there a translation for a new language? If yes, [register the language with the app's langauge selector](https://github.com/TeamNewPipe/NewPipe/pull/5721)
110 | - Use `Analyse > Inspect Code` in Android Studio to find unused strings and potential bugs introduced by Weblate.
111 | Pay attention to plurals in Asian languages. They are broken by Weblate on a regular basis.
112 |
113 | Push the changes to NewPipe's `dev` branch, [update Weblate](#update-weblate) and unlock it.
114 |
--------------------------------------------------------------------------------
/docs/img/InfoItemsCollector_objectdiagram.svg:
--------------------------------------------------------------------------------
1 |
2 |
3 |