be-gay-do-crimes
/
newpipe-documentation
mirror of https://github.com/TeamNewPipe/documentation
1
0
Fork 0
Code Issues Releases Wiki Activity

Deployed a05b04c with MkDocs version: 1.2.3

This commit is contained in:
TobiGr 2021-10-21 01:09:50 +02:00
parent abfc6b4d3a
commit 3c1f47884b
20 changed files with 522 additions and 269 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

23
00_Prepare_everything/index.html
View File

@ -31,7 +31,6 @@
<script src="../js/modernizr-2.8.3.min.js" defer></script>
<script src="../js/highlight.min.js"></script>
<script>hljs.initHighlightingOnLoad();</script>
</head>
<body class="wy-body-for-nav" role="document">
@ -45,7 +44,7 @@
<a href=".." class="icon icon-home"> NewPipe Documentation</a>
<div role="search">
<form id ="rtd-search-form" class="wy-form" action="../search.html" method="get">
<input type="text" name="q" placeholder="Search docs" title="Type search term here" />
<input type="text" name="q" placeholder="Search docs" title="Type search term here" />
</form>
</div>
</div>
@ -130,6 +129,7 @@
<hr/>
</div>
<div role="main">
<div class="section">
@ -239,17 +239,18 @@ As Gradle Project, select NewPipeExtractor. As a task, add "test". Now save and
</div>
<div class="rst-versions" role="note" aria-label="versions">
<span class="rst-current-version" data-toggle="rst-current-version">
<span><a href=".." style="color: #fcfcfc;">&laquo; Previous</a></span>
<span style="margin-left: 15px"><a href="../01_Concept_of_the_extractor/" style="color: #fcfcfc">Next &raquo;</a></span>
</span>
<span class="rst-current-version" data-toggle="rst-current-version">
<span><a href=".." style="color: #fcfcfc">&laquo; Previous</a></span>
<span><a href="../01_Concept_of_the_extractor/" style="color: #fcfcfc">Next &raquo;</a></span>
</span>
</div>
<script>var base_url = '..';</script>
<script src="../js/theme_extra.js" defer></script>
<script src="../js/theme.js" defer></script>
<script src="../search/main.js" defer></script>
<script defer>

30
01_Concept_of_the_extractor/index.html
View File

@ -31,7 +31,6 @@
<script src="../js/modernizr-2.8.3.min.js" defer></script>
<script src="../js/highlight.min.js"></script>
<script>hljs.initHighlightingOnLoad();</script>
</head>
<body class="wy-body-for-nav" role="document">
@ -45,7 +44,7 @@
<a href=".." class="icon icon-home"> NewPipe Documentation</a>
<div role="search">
<form id ="rtd-search-form" class="wy-form" action="../search.html" method="get">
<input type="text" name="q" placeholder="Search docs" title="Type search term here" />
<input type="text" name="q" placeholder="Search docs" title="Type search term here" />
</form>
</div>
</div>
@ -130,6 +129,7 @@
<hr/>
</div>
<div role="main">
<div class="section">
@ -145,7 +145,7 @@ multiple methods, one method for every data field the collector wants to have. T
You need to take care of the extractors.</p>
<h3 id="usage-in-the-front-end">Usage in the Front End</h3>
<p>A typical call for retrieving data from a website would look like this:</p>
<pre><code class="java">Info info;
<pre><code class="language-java">Info info;
try {
// Create a new Extractor with a given context provided as parameter.
Extractor extractor = new Extractor(some_meta_info);
@ -155,10 +155,9 @@ try {
// handle errors when collector decided to break up extraction
}
</code></pre>
<h3 id="typical-implementation-of-a-single-data-extractor">Typical Implementation of a Single Data Extractor</h3>
<p>The typical implementation of a single data extractor, on the other hand, would look like this:</p>
<pre><code class="java">class MyExtractor extends FutureExtractor {
<pre><code class="language-java">class MyExtractor extends FutureExtractor {
public MyExtractor(RequiredInfo requiredInfo, ForExtraction forExtraction) {
super(requiredInfo, forExtraction);
@ -180,7 +179,6 @@ try {
... // More datafields
}
</code></pre>
<h2 id="collectorextractor-pattern-for-lists">Collector/Extractor Pattern for Lists</h2>
<p>Information can be represented as a list. In NewPipe, a list is represented by an
<a href="https://teamnewpipe.github.io/NewPipeExtractor/javadoc/org/schabi/newpipe/extractor/InfoItemsCollector.html">InfoItemsCollector</a>.
@ -213,7 +211,6 @@ that will be able to retrieve data for one and only one InfoItem. This extractor
}
</code></pre>
<h2 id="listextractor">ListExtractor</h2>
<p>There is more to know about lists:</p>
<ol>
@ -313,17 +310,18 @@ items like a regular web page, but all the others as an AJAX request.</p>
</div>
<div class="rst-versions" role="note" aria-label="versions">
<span class="rst-current-version" data-toggle="rst-current-version">
<span><a href="../00_Prepare_everything/" style="color: #fcfcfc;">&laquo; Previous</a></span>
<span style="margin-left: 15px"><a href="../02_Concept_of_LinkHandler/" style="color: #fcfcfc">Next &raquo;</a></span>
</span>
<span class="rst-current-version" data-toggle="rst-current-version">
<span><a href="../00_Prepare_everything/" style="color: #fcfcfc">&laquo; Previous</a></span>
<span><a href="../02_Concept_of_LinkHandler/" style="color: #fcfcfc">Next &raquo;</a></span>
</span>
</div>
<script>var base_url = '..';</script>
<script src="../js/theme_extra.js" defer></script>
<script src="../js/theme.js" defer></script>
<script src="../search/main.js" defer></script>
<script defer>

29
02_Concept_of_LinkHandler/index.html
View File

@ -31,7 +31,6 @@
<script src="../js/modernizr-2.8.3.min.js" defer></script>
<script src="../js/highlight.min.js"></script>
<script>hljs.initHighlightingOnLoad();</script>
</head>
<body class="wy-body-for-nav" role="document">
@ -45,7 +44,7 @@
<a href=".." class="icon icon-home"> NewPipe Documentation</a>
<div role="search">
<form id ="rtd-search-form" class="wy-form" action="../search.html" method="get">
<input type="text" name="q" placeholder="Search docs" title="Type search term here" />
<input type="text" name="q" placeholder="Search docs" title="Type search term here" />
</form>
</div>
</div>
@ -130,6 +129,7 @@
<hr/>
</div>
<div role="main">
<div class="section">
@ -155,13 +155,12 @@ one unique ID that represents it, like this example:</p>
</ul>
<h3 id="usage">Usage</h3>
<p>The typical usage for obtaining a LinkHandler would look like this:</p>
<pre><code class="java">LinkHandlerFactory myLinkHandlerFactory = new MyStreamLinkHandlerFactory();
<pre><code class="language-java">LinkHandlerFactory myLinkHandlerFactory = new MyStreamLinkHandlerFactory();
LinkHandler myVideo = myLinkHandlerFactory.fromUrl(&quot;https://my.service.com/the_video&quot;);
</code></pre>
<h3 id="implementation">Implementation</h3>
<p>In order to use LinkHandler for your service, you must override the appropriate LinkHandlerFactory. eg:</p>
<pre><code class="java">class MyStreamLinkHandlerFactory extends LinkHandlerFactory {
<pre><code class="language-java">class MyStreamLinkHandlerFactory extends LinkHandlerFactory {
@Override
public String getId(String url) throws ParsingException {
@ -179,7 +178,6 @@ LinkHandler myVideo = myLinkHandlerFactory.fromUrl(&quot;https://my.service.com/
}
}
</code></pre>
<h3 id="listlinkhandler-and-searchqueryhandler">ListLinkHandler and SearchQueryHandler</h3>
<p>List based resources, like channels and playlists, can be sorted and filtered.
Therefore these type of resources don't just use a LinkHandler, but a class called
@ -234,17 +232,18 @@ and <code>getId()</code> when overriding <a href="https://teamnewpipe.github.io/
</div>
<div class="rst-versions" role="note" aria-label="versions">
<span class="rst-current-version" data-toggle="rst-current-version">
<span><a href="../01_Concept_of_the_extractor/" style="color: #fcfcfc;">&laquo; Previous</a></span>
<span style="margin-left: 15px"><a href="../03_Implement_a_service/" style="color: #fcfcfc">Next &raquo;</a></span>
</span>
<span class="rst-current-version" data-toggle="rst-current-version">
<span><a href="../01_Concept_of_the_extractor/" style="color: #fcfcfc">&laquo; Previous</a></span>
<span><a href="../03_Implement_a_service/" style="color: #fcfcfc">Next &raquo;</a></span>
</span>
</div>
<script>var base_url = '..';</script>
<script src="../js/theme_extra.js" defer></script>
<script src="../js/theme.js" defer></script>
<script src="../search/main.js" defer></script>
<script defer>

26
03_Implement_a_service/index.html
View File

@ -31,7 +31,6 @@
<script src="../js/modernizr-2.8.3.min.js" defer></script>
<script src="../js/highlight.min.js"></script>
<script>hljs.initHighlightingOnLoad();</script>
</head>
<body class="wy-body-for-nav" role="document">
@ -45,7 +44,7 @@
<a href=".." class="icon icon-home"> NewPipe Documentation</a>
<div role="search">
<form id ="rtd-search-form" class="wy-form" action="../search.html" method="get">
<input type="text" name="q" placeholder="Search docs" title="Type search term here" />
<input type="text" name="q" placeholder="Search docs" title="Type search term here" />
</form>
</div>
</div>
@ -138,6 +137,7 @@
<hr/>
</div>
<div role="main">
<div class="section">
@ -259,7 +259,7 @@ through the <strong>KioskList.KioskExtractorFactory</strong>.</p>
<p>An example implementation of the
<a href="https://teamnewpipe.github.io/NewPipeExtractor/javadoc/org/schabi/newpipe/extractor/StreamingService.html">getKioskList()</a>
could look like this:</p>
<pre><code class="java">@Override
<pre><code class="language-java">@Override
public KioskList getKioskList() throws ExtractionException {
KioskList list = new KioskList(getServiceId());
@ -280,7 +280,6 @@ public KioskList getKioskList() throws ExtractionException {
}
</code></pre>
<p><strong>Parts Required to be Implemented:</strong></p>
<ul>
<li><a href="https://teamnewpipe.github.io/NewPipeExtractor/javadoc/org/schabi/newpipe/extractor/kiosk/KioskList.KioskExtractorFactory.html">KioskList.KioskExtractorFactory</a></li>
@ -320,17 +319,18 @@ public KioskList getKioskList() throws ExtractionException {
</div>
<div class="rst-versions" role="note" aria-label="versions">
<span class="rst-current-version" data-toggle="rst-current-version">
<span><a href="../02_Concept_of_LinkHandler/" style="color: #fcfcfc;">&laquo; Previous</a></span>
<span style="margin-left: 15px"><a href="../04_Run_changes_in_App/" style="color: #fcfcfc">Next &raquo;</a></span>
</span>
<span class="rst-current-version" data-toggle="rst-current-version">
<span><a href="../02_Concept_of_LinkHandler/" style="color: #fcfcfc">&laquo; Previous</a></span>
<span><a href="../04_Run_changes_in_App/" style="color: #fcfcfc">Next &raquo;</a></span>
</span>
</div>
<script>var base_url = '..';</script>
<script src="../js/theme_extra.js" defer></script>
<script src="../js/theme.js" defer></script>
<script src="../search/main.js" defer></script>
<script defer>

24
04_Run_changes_in_App/index.html
View File

@ -31,7 +31,6 @@
<script src="../js/modernizr-2.8.3.min.js" defer></script>
<script src="../js/highlight.min.js"></script>
<script>hljs.initHighlightingOnLoad();</script>
</head>
<body class="wy-body-for-nav" role="document">
@ -45,7 +44,7 @@
<a href=".." class="icon icon-home"> NewPipe Documentation</a>
<div role="search">
<form id ="rtd-search-form" class="wy-form" action="../search.html" method="get">
<input type="text" name="q" placeholder="Search docs" title="Type search term here" />
<input type="text" name="q" placeholder="Search docs" title="Type search term here" />
</form>
</div>
</div>
@ -132,6 +131,7 @@
<hr/>
</div>
<div role="main">
<div class="section">
@ -161,7 +161,6 @@ sometimes have to adjust the udev rules in order to
}
}
</code></pre>
<p><code>includeBuild</code> should have the relative path as argument. <code>../NewPipeExtractor</code> means one folder up in hierarchy,
and the folder is exactly named <code>NewPipeExtractor</code>. If that's not the case, edit this part.</p>
<h4 id="using-jitpack">Using JitPack</h4>
@ -219,17 +218,18 @@ click on that little paper symbol next to the <code>GET IT</code> button. If it'
</div>
<div class="rst-versions" role="note" aria-label="versions">
<span class="rst-current-version" data-toggle="rst-current-version">
<span><a href="../03_Implement_a_service/" style="color: #fcfcfc;">&laquo; Previous</a></span>
<span style="margin-left: 15px"><a href="../05_releasing/" style="color: #fcfcfc">Next &raquo;</a></span>
</span>
<span class="rst-current-version" data-toggle="rst-current-version">
<span><a href="../03_Implement_a_service/" style="color: #fcfcfc">&laquo; Previous</a></span>
<span><a href="../05_releasing/" style="color: #fcfcfc">Next &raquo;</a></span>
</span>
</div>
<script>var base_url = '..';</script>
<script src="../js/theme_extra.js" defer></script>
<script src="../js/theme.js" defer></script>
<script src="../search/main.js" defer></script>
<script defer>

326
05_releasing/index.html
View File

@ -31,7 +31,6 @@
<script src="../js/modernizr-2.8.3.min.js" defer></script>
<script src="../js/highlight.min.js"></script>
<script>hljs.initHighlightingOnLoad();</script>
</head>
<body class="wy-body-for-nav" role="document">
@ -45,7 +44,7 @@
<a href=".." class="icon icon-home"> NewPipe Documentation</a>
<div role="search">
<form id ="rtd-search-form" class="wy-form" action="../search.html" method="get">
<input type="text" name="q" placeholder="Search docs" title="Type search term here" />
<input type="text" name="q" placeholder="Search docs" title="Type search term here" />
</form>
</div>
</div>
@ -102,15 +101,21 @@
</li>
</ul>
</li>
<li class="toctree-l2"><a class="reference internal" href="#extractor-releases">Extractor releases</a>
</li>
<li class="toctree-l2"><a class="reference internal" href="#version-nomenclature">Version Nomenclature</a>
<ul>
<li class="toctree-l3"><a class="reference internal" href="#version-nomenclature-of-the-extractor">Version Nomenclature of the Extractor</a>
</li>
<li class="toctree-l3"><a class="reference internal" href="#version-code">Version Code</a>
</li>
</ul>
</li>
<li class="toctree-l2"><a class="reference internal" href="#release-notes">Release Notes</a>
<ul>
<li class="toctree-l3"><a class="reference internal" href="#changelog-file">Changelog file</a>
</li>
</ul>
</li>
<li class="toctree-l2"><a class="reference internal" href="#publish-on-f-droid">Publish on F-Droid</a>
</li>
</ul>
</li>
@ -152,6 +157,7 @@
<hr/>
</div>
<div role="main">
<div class="section">
@ -159,82 +165,120 @@
<p>This site is meant for those who want to maintain NewPipe, or just want to know how releasing works.</p>
<p><img alt="one does not simply push to master" src="../img/onedoes.jpg" /></p>
<h2 id="differences-between-regular-and-hotfix-releases">Differences Between Regular and Hotfix Releases</h2>
<p>NewPipe is a web crawler. That means it does not use a web API, but instead tries to scrape the data from the website,
this however has the disadvantage of the app to break instantly when YouTube changes something.
We do not know when this happen. Therefore, maintainers need to act quickly when it happens, and reduce our downtime as
<p>Depending on the service, NewPipe Extractor uses web crawling or internal APIs.
Both are subject to arbitrary changes by the service providers, like YouTube, SoundCloud or PeerTube.
When they change something, NewPipe Extractor and thus NewPipe break instantly.
Therefore, maintainers need to act quickly when it happens, and reduce our downtime as
much as possible. The entire release cycle is therefore designed around this issue.</p>
<p>There is a difference between a release that introduces new features
and a release that fixes an issue that occurred because YouTube, or some other service, changed their website (typically called a shutdown).
Lets have a look at the characteristics of a <strong>regular release</strong>, and then the characteristics of a <strong>hotfix release</strong>.</p>
and a release that fixes an issue that occurred because YouTube, or some other service,
changed their website (typically called a shutdown).
Let's have a look at the characteristics of a <strong>regular release</strong>,
and then the characteristics of a <strong>hotfix release</strong>.</p>
<h2 id="regular-releases">Regular Releases</h2>
<p>Regular releases are normal releases like they are done in any other app. Releases are always stored on <strong>master</strong> branch. The latest commit on
<strong>master</strong> is always equal to the currently released version. No development is done on master. This ensures that we always have one
branch with a stable/releasable version.</p>
<p>Regular releases are normal releases as they are done in any other app.
Releases are always stored and tagged on <strong>master</strong> branch. The latest commit on
<strong>master</strong> is always equal to the currently released version. No development is done on master.
This ensures that we always have one branch with a stable/releasable version.</p>
<h3 id="feature-branching">Feature Branching</h3>
<p>When developing, the <strong>dev</strong> branch is used. Pushing to <strong>dev</strong> directly, however, is not allowed, since QA and testing should be done first before adding something to it.
This ensures that the dev version works as stable a possible.
In order to change something on the app, one may want to <strong>fork</strong> the dev branch and develop the changes in their own branch (this is called feature branching).</p>
<p>The <strong>dev</strong> branch is used for development. Pushing to <strong>dev</strong> directly, however, is not allowed,
since QA and testing should be done <em>before</em> adding something to the branch.
This ensures that the development version works as stable a possible.
In order to change something on the app, one may want to <strong>fork</strong> the dev branch
and develop the changes in their own branch (this is called feature branching).</p>
<p><img alt="feature_branching" src="../img/feature_branch.svg" /></p>
<p>Make sure that both the dev branches, as well as the master branches of the extractor and the frontend, are compatible with each other.
If a change is done on the API to the extractor, make sure that frontend is compatible, or changed to become compatible, with these changes. If the PR that should make the frontend compatible
again can not be merged, please do not merge the corresponding PR on the extractor either. This should make sure that any developer can run his changes
on the fronted at any time.</p>
<p>Make sure that both the dev branches, as well as the master branches of the extractor
and the frontend, are compatible with each other.
If the extractor's API is modified, make sure that frontend is compatible,
or changed to become compatible, with these changes.
If the PR that should make the frontend compatible
again can not be merged, please do not merge the corresponding PR on the extractor either.
This should make sure that any developer can run his changes on the fronted at any time.</p>
<h3 id="merging-featuresbugfixes">Merging Features/Bugfixes</h3>
<p>After finishing a feature, one should open up a <strong>Pull Request</strong> to the dev branch. From here, a maintainer can do <strong>Code review</strong> and <strong>Quality Assurance (QA)</strong>.
If you are a maintainer, please take care about the code architecture so <strong>corrosion</strong> or <strong>code shifting</strong> can be prevented. Please also prioritize code quality over functionality.
In short: cool function but bad code = no merge. Focus on leaving the code as clean as possible.</p>
<p>After finishing a feature, one should open up a <strong>Pull Request</strong> to the dev branch.
From here, a maintainer can do <strong>Code review</strong> and <strong>Quality Assurance (QA)</strong>.
If you are a maintainer, please take care about the code architecture
so <strong>corrosion</strong> or <strong>code shifting</strong> can be prevented.
Please also prioritize code quality over functionality.<br />
In short: cool function but bad code = no merge. Focus on keeping the code as clean as possible.</p>
<p><img alt="merge_feature_into_dev" src="../img/merge_into_dev.svg" /></p>
<p>You, as a maintainer, should build the app and put the signed APK into the description of that new pull request. This way, other people can test the feature/bugfix and help with QA. <em>You may not need to do this every time. It is enough to do it on bigger pull requests.</em></p>
<p>After the maintainer merges the new feature into the dev branch, he should add the title of the pull request or a summary of the changes into the <a href="#release-notes">release notes</a>.</p>
<p>An APK for <strong>testing</strong> is provided by GitHub Actions for every PR.
Please ensure that this APK is tested thoroughly to prevent introducing regressions.
Testing features needs to take into account that NewPipe is used on a brought variety
of Android versions from KitKat to the latest, on custom ROMs like Lineage OS, CalyxOS or /e/
and different devices like phones, tablets and TVs.</p>
<p>Sometimes, the content of a PR changes over the time.
Modify the PR's title if it does not represent the introduced changes anymore.
After a maintainer merged the new feature into the dev branch,
they should add the PR's title or a summary of the changes into the <a href="#release-notes">release notes</a>.</p>
<h3 id="creating-a-new-release">Creating a New Release</h3>
<p>Once there are enough features together, and the maintainers believe that NewPipe is ready for a new release, they should create a new release.
Be aware of the rule that a release should never be done on a Friday. For NewPipe, this means: <strong>Don't do a release if you don't have time for it!!!</strong>
Below is a list of things you will want to do:</p>
<p>Once there are enough changes, and the maintainers believe that NewPipe is ready
for a new version, they should prepare a new release.<br />
Be aware of the rule that a release should never be done on a Friday.
For NewPipe, this means: <strong>Don't do a release if you don't have time for it!!!</strong></p>
<p>By following the steps listed below, you can publish a stable version of NewPipe:</p>
<ol>
<li>Fork the <strong>dev</strong> branch into a new <strong>release_x.y.z</strong> branch.</li>
<li>Increase the <a href="#version-nomenclature">version number</a></li>
<li>Merge <a href="https://hosted.weblate.org/projects/newpipe/">Weblate</a> changes from the <code>dev</code> branch at <code>https://hosted.weblate.org/git/newpipe/strings/</code>.</li>
<li>Copy the <a href="#release-notes">release notes</a> from the GitHub version draft into the corresponding fastlane file (see <a href="#release-notes">release notes</a>).</li>
<li>Open up a pull request form the new <strong>release_x.y.z</strong> branch into the <strong>master</strong> branch.</li>
<li>Create an issue pointing to the new pull request. The reason for opening an issue is that from my perception, people read issues more than pull requests. Put the release-note into this pull request.</li>
<li>Build a signed release version of NewPipe using schabis signing keys. This is a release candidate (RC). Name the build apk file <code>NewPipe_&lt;versionNumber&gt;_RC1.apk</code>.
Zip it and post it to the head of the release issue. This way, others can test the release candidate.</li>
<li>Test and QA the new version with the help of others.</li>
<li>Leave the PR open for a few days and advertise it to help testing.</li>
<li><a href="../07_maintainers_view#merge-changes-from-weblate-into-newpipe">Merge the translations from Weblate into NewPipe</a>.</li>
<li>Update your local <strong>dev</strong> branch and create a <a href="#changelog-file">changelog file</a>.
Make sure to push the changes and <a href="../07_maintainers_view#update-weblate">update Weblate</a>.</li>
<li>In your local NewPipe repo, fork the <strong>dev</strong> branch into a new <strong>release/x.y.z</strong> branch. </li>
<li>Increase the <a href="#version-nomenclature">version number</a> and update the version code in the <code>build.gradle</code> file.</li>
<li>Open a pull request form the new <strong>release/x.y.z</strong> branch into the <strong>master</strong> branch.</li>
<li>Create an issue pointing to the new pull request.
The reason for opening an issue is that from my perception, people read issues more than pull requests.
You can also pin this issue to draw more attention to it.
Ensure that the discussion about regressions take place in this issue.</li>
<li>Create signed release and debug APKs of the release branch using the <code>releaseCandidate</code> and <code>debug</code> build types.
Name the build apk files <code>NewPipe_&lt;versionCode&gt;_RC1.apk</code> and <code>NewPipe_&lt;versionCode&gt;_debug_RC1.apk</code>.
Zip and post them to the head of the pull request and issue. This way, others can test the release candidate.
Release (candidate) and debug APKs of the latest published NewPipe version
should also be provided to allow testing the upgrade process.</li>
<li>Test and QA the new version with the help of others. Keep the PR and issue open for a few days</li>
</ol>
<p>While being in release phase no new pull requests must be merged into <strong>dev</strong> branch.</p>
<p>This procedure does not have to be done for the extractor as extractor will be tested together with the fronted.</p>
<p>New features can be merged into <strong>dev</strong> while the release candidate is tested.
PRs which aim to fix regressions of the upcoming release need to target the <strong>release/x.y.z</strong> branch.
Read <a href="#quickfixes">Quickfixes</a> for more info.</p>
<p>The changelogs are translated during the test phase.
Therefore, <a href="../07_maintainers_view#merge-changes-from-weblate-into-newpipe">the translations need to be merged from Weblate</a> once more.
The translation commit is cherry-picked into the release branch.</p>
<p>Once testing is done and the release branch does not contain critical regressions, and you think the update is ready,
proceed with <a href="#releasing">releasing the new version</a>.</p>
<h3 id="quickfixes">Quickfixes</h3>
<p>When issuing a new release, you will most likely encounter bugs that might not have existed in previous versions. These are called <strong>regressions</strong>.
If you find a regression during release phase, you are allowed to push fixes directly into the release branch without having to fork a branch away from it.
All maintainers have to be aware that they might be required to fix regressions, so plan your release at a time when
you are available. Do not introduce new features during the release phase.</p>
<p>When you have pushed a quickfix, you will want to update the <strong>release candidate</strong> you put into the <strong>issue</strong> corresponding to the <strong>release pull request</strong>.
Increment the version number in the filename of the release candidate. e.g. <code>NewPipe_&lt;versionNumber&gt;_RC2.apk</code> etc. <em>Don't update the actual version number. :P</em></p>
<p>When issuing a new release, you will most likely encounter bugs
that might not have existed in previous versions.
These are called <strong>regressions</strong>.
If you find a regression during release phase,
you are allowed to push fixes directly into the release branch
without having to fork a branch away from it.
Maintainers have to be aware that they might be required to fix regressions,
so plan your release at a time when you are available.</p>
<p>When you have pushed a quickfix, you need to provide an updated <strong>release candidate</strong>.
Increment the version number in the filename of the release candidate. e.g. <code>NewPipe_&lt;versionNumber&gt;_RC2.apk</code> etc.
<em>Don't update the actual version number. :P</em></p>
<p><img alt="release_branch" src="../img/release_branch.svg" /></p>
<h3 id="releasing">Releasing</h3>
<p>Once the glorious day of all days has come, and you fulfill the ceremony of releasing.
After going through the release procedure of <a href="#create_a_new_release">creating a new release</a> and maybe a few <a href="#quickfixes">quickfixes</a> on the new release,
After going through the release procedure of <a href="#create_a_new_release">creating a new release</a>
and maybe a few <a href="#quickfixes">quickfixes</a> on the new release,
this is what you should do when releasing:</p>
<ol>
<li>Click "Merge Pull Request".</li>
<li>Create a GPG signed tag with the name <code>v0.x.y</code>.</li>
<li>Merge <strong>dev</strong> into master on the extractor.</li>
<li>Create a GPG signed tag with the name <code>v0.x.y</code> on the extractor.</li>
<li>Make sure the draft name equals the tag name. <img alt="draft_name" src="../img/draft_name.png" /></li>
<li>Checkout the <strong>master</strong> branch locally and create an unsigned APK.</li>
<li>Send this APK to TheAssassin for signing and publishing in an encrypted and signed E-Mail. He'll check your APK, too.</li>
<li>Once you received a signed APK, upgrade the version on your device and look for any crashes and regressions.</li>
<li>In the GitHub releases section, make sure the draft name equals the tag name. <img alt="draft_name" src="../img/draft_name.png" /></li>
<li>Add the signed APK to the draft. </li>
<li>Make sure to not have forgotten anything.</li>
<li>Click "Publish Release".</li>
<li>Clone <a href="https://gitlab.com/fdroid/fdroiddata">F-Droid / Data</a>.</li>
<li>Add the new version in <code>metadata/org.schabi.newpipe.yml</code>.</li>
<li>Run <code>fdroid signatures /path/to/newpipe.apk</code>.</li>
<li>Create a MR.</li>
<li>Rebase quickfix changes back into <strong>dev</strong> if quickfixes were made.</li>
<li>Temporarily: <a href="https://github.com/TeamNewPipe/website/blob/master/_includes/release_data.html">Update the changelog for the website</a>.</li>
<li><a href="#publish-on-f-droid">Publish the new version on F-Droid</a>.</li>
<li>Merge <strong>master</strong> into <strong>dev</strong> or fast-forward if possible. Push.</li>
<li><a href="https://github.com/TeamNewPipe/website/blob/master/_includes/release_data.html">Update the changelog for the website</a>.</li>
</ol>
<p><img alt="rebase_back" src="../img/rebase_back_release.svg" /></p>
<h2 id="hotfix-releases">Hotfix Releases</h2>
<p><img alt="this_is_fine" src="../img/could_not_decrypt.png" /></p>
<p>As aforementioned, NewPipe is a web crawler and could break at any moment. In order to keep the downtime of NewPipe as low as possible, when such a shutdown happens,
<p>As aforementioned, NewPipe heavily relies on external components and might break at a random point of time.
In order to keep the NewPipe's downtime as low as possible, when such a shutdown happens,
we allow <strong>hotfixes</strong>.</p>
<ul>
<li>A hotfix allows work on the master branch instead of the dev branch.</li>
@ -242,56 +286,141 @@ we allow <strong>hotfixes</strong>.</p>
<li>A hotfix may only focus on fixing what caused the shutdown.</li>
</ul>
<h3 id="hotfix-branch">Hotfix Branch</h3>
<p>Hotfixes work on the master branch. The dev branch has experimental changes that might have not been tested properly enough to be released, if at all. The master branch should always be the latest stable version of NewPipe. If the master branch breaks due to a shutdown, you should fix the master branch.
Of course you are not allowed to push to master directly so you will have to open up a <strong>hotfix</strong> branch. <em>If someone else is pushing a hotfix into master, and it works this can be considered as hotfix branch as well.</em></p>
<p>Hotfixes work on the master branch.
The dev branch has experimental changes that might have not been tested properly enough to be released,
if at all. The master branch should always be the latest stable version of NewPipe.
If the master branch breaks due to a shutdown, you should fix the master branch.
Of course, you are not allowed to push to master directly,
so you need to create a <strong>hotfix</strong> branch.
<em>If someone else is pushing a hotfix into master, and it works this can be considered as hotfix branch as well.</em></p>
<p><img alt="hotfix_branch" src="../img/hotfix_branch.svg" /></p>
<h3 id="releasing_1">Releasing</h3>
<p>If you fixed the issue and found it to be tested and reviewed well enough, you may release it. You don't need to undergo the full release procedure of a regular release, which takes more time to release.
<p>If you fixed the issue and found it to be tested and reviewed well enough, you may publish a new version.
You don't need to undergo the full release procedure of a regular release, which takes too much time.
Keep in mind that if the hotfix might turn out to be broken after release, you should release another hotfix.
It is important to release quickly for the sake of keeping NewPipe alive, and after all, a slightly broken version of NewPipe is better then a non-functional version ¯\_(ツ)_/¯.
It is important to release quickly for the sake of keeping NewPipe alive, and after all,
a slightly broken version of NewPipe is better than a non-functional version ¯\_(ツ)_/¯.
Here's what you do when releasing a hotfix:</p>
<ol>
<li>Click "Merge Pull Request"</li>
<li>Create a GPG signed tag with the name <code>v0.x.y</code>.</li>
<li>Merge <strong>dev</strong> into master on the extractor.</li>
<li>Create a GPG signed tag with the name <code>v0.x.y</code> on the extractor.</li>
<li>Create a new release draft and write the down the fix into the release notes.</li>
<li>Copy the <a href="#release-notes">release note</a> into the fastlane directory of releases.</li>
<li>Merge the corresponding pull request in the extractor.</li>
<li><a href="#extractor-releases">Publish the new extractor version</a>.</li>
<li>Update the extractor version in the app's <code>build.gradle</code> file.</li>
<li>Create a new release draft and put some info on the fix into the <a href="#release-notes">release note</a>.</li>
<li>Copy the release notes into the fastlane directory to create a <a href="#changelog-file">changelog file</a>.</li>
<li>Increment the <strong>small minor</strong> version number and the <code>versionCode</code>.</li>
<li>Click "Publish Release".</li>
<li>Clone <a href="https://gitlab.com/fdroid/fdroiddata">F-Droid / Data</a>.</li>
<li>Add the new version in <code>metadata/org.schabi.newpipe.yml</code>.</li>
<li>Run <code>fdroid signatures /path/to/newpipe.apk</code>.</li>
<li>Create a MR.</li>
<li>Rebase the hotfix back into <strong>dev</strong> branch.</li>
<li>Temporarily: <a href="https://github.com/TeamNewPipe/website/blob/master/_includes/release_data.html">Update the changelog for the website</a>.</li>
<li>Generate a release APK (<code>gradlew assembleRelease</code>) and sign it (or get it signed by one of the other maintainers).</li>
<li>Add the signed APK to the GitHub release notes.</li>
<li>Click "Publish Release" .</li>
<li><a href="#publish-on-f-droid">Publish the new version on F-Droid</a>.</li>
<li>Merge the changes from <strong>master</strong> into <strong>dev</strong>.</li>
<li><a href="https://github.com/TeamNewPipe/website/blob/master/_includes/release_data.html">Update the changelog for the website</a>.</li>
</ol>
<p><img alt="rebase_back_hotfix" src="../img/rebase_back_hotfix.svg" /></p>
<h2 id="extractor-releases">Extractor releases</h2>
<p>In general, the release process for extractor versions is not that complicated compared to app releases.
The extractor has (in difference to the app) a decent test coverage.
Additionally, the latest extractor version is typically tested in the app's latest <strong>dev</strong> version.
Therefore, a long test phase is not needed when creating extractor releases.</p>
<p>To create a new <a href="#version-nomenclature-of-the-extractor">extractor version</a>, update the <strong>version</strong> in the extractor's <code>build.gradle</code> file
as well as the version names in the README.
Merge the <strong>dev</strong> branch into <strong>master</strong>.
The same that applies the app's <a href="#release-notes">release notes</a> also applies to the extractor's release notes.</p>
<p>When publishing an extractor release via GitHub on the <strong>master</strong> branch,
a new <a href="https://teamnewpipe.github.io/NewPipeExtractor/javadoc/">JavaDoc version</a>
is generated and published automatically.
Pleas keep an eye on the GitHub Action which is responsible for that.
If changes in that release introduced invalid JavaDoc, the build fails and needs to be fixed.
For this reason, you should check locally if there are any problems with the JavaDoc generation before publishing the new version.</p>
<h2 id="version-nomenclature">Version Nomenclature</h2>
<p>The version nomenclature of NewPipe is simple.</p>
<ul>
<li><strong>Major</strong>: The <strong>major</strong> version number (the number before the first dot) was 0 for years. The reason for this changed over time. First, I wanted this number to
switch to 1 once NewPipe was feature complete. Now, I rather think of incrementing this number to 1 once we can ensure that NewPipe runs stable (part of which this documentation should help). After this, well, God knows what happens if we ever reach 1. ¯\_(ツ)_/¯ </li>
<li><strong>Minor</strong>: The <strong>minor</strong> version number (the number after the first dot) will be incremented if there is a major feature added to the app.</li>
<li><strong>Small Minor</strong>: The small minor (the number after the second dot) will be incremented if there are bug fixes or minor features added to the app.</li>
<li><strong>Major</strong>: The <strong>major</strong> version number (the number before the first dot) was 0 for years.
The reason for this changed over time. First, I wanted this number to
switch to 1 once NewPipe was feature complete.
Now, I rather think of incrementing this number to 1 once we can ensure that NewPipe runs stable
(part of which this documentation should help).
After this, well, God knows what happens if we ever reach 1. ¯\_(ツ)_/¯ </li>
<li><strong>Minor</strong>: The <strong>minor</strong> version number (the number after the first dot)
will be incremented if there is a major feature added to the app.</li>
<li><strong>Small Minor</strong>: The small minor (the number after the second dot)
is incremented when bug fixes or minor features are added to the app.</li>
</ul>
<h4 id="version-nomenclature-of-the-extractor">Version Nomenclature of the Extractor</h4>
<p>The extractor is always released together with the app, therefore the version number of the extractor is identical to the one of NewPipe itself.</p>
<h4 id="version-code">Version Code</h4>
<p>In Android, an app can also have a <a href="https://developer.android.com/studio/publish/versioning">versionCode</a>. This code is a <code>long integer</code> and can be incremented by any value to show a device that a new version is there.
For NewPipe, the version code will be incremented by 10 regardless of the change of the major or minor version number. The version codes between the 10 steps
are reserved for our internal F-Droid build server.</p>
<p>Previously, the extractor was released together with the app,
therefore the version number of the extractor was identical to the one of NewPipe itself.</p>
<p>We try to combine efforts to make NewPipe Extractor more independent of the app.
The extractor is used by multiple other applications
and therefore releasing extractor updates should not be coupled to app releases.
However, maintainers need to keep an eye on making the app compatible with extractor changes.</p>
<h2 id="release-notes">Release Notes</h2>
<p>Release notes should tell what was changed in the new version of the app. The release nodes for NewPipe are stored in the <a href="https://github.com/TeamNewPipe/NewPipe/releases/tag/v0.14.0">GitHub draft for a new release</a>. When a maintainer wants to add changes to the release note, but there is no draft for a new version, they should create one.</p>
<p>Changes can be categorized into three types:</p>
<p>Release notes should tell what was changed in the new version of the app.
The release notes for NewPipe are stored in the
<a href="https://github.com/TeamNewPipe/NewPipe/releases">GitHub draft for a new release</a>.
When a maintainer wants to add changes to the release notes,
but there is no draft for a new version, they should create one.</p>
<p>Changes can be categorized into five basic types:</p>
<ul>
<li><strong>New</strong>: New features that got added to the app.</li>
<li><strong>Improved</strong>: Improvements to the app or existing features</li>
<li><strong>Fixes</strong>: Bugfixes</li>
<li><strong>Fixed</strong>: Bugfixes</li>
<li><strong>Translation</strong>: New translations</li>
<li><strong>Development</strong>: Changes which address things "under the hood",
which do not have any recognizable effect to the user; e.g. dependency updates or changes to the build process</li>
</ul>
<p>When releasing a new version of NewPipe, before actually clicking "Release", the maintainer should copy the release notes from the draft and put it into a file called
<code>&lt;versionCode&gt;.txt</code> (whereas <code>&lt;versionCode&gt;</code> needs to be the version code of the incoming release). This file must be stored in the directory <a href="https://github.com/teamnewpipe/newpipe/tree/dev/fastlane/metadata/android/en-US/changelogs"><code>/fastlane/metadata/android/en-US/changelogs</code></a>. This way, F-Droid will be able to show the
changes done to the app.</p>
<p>When adding a PR to the release notes, increase the PR counter at the top of the draft
and put the number before the PR summary / title.
This helps the blog post authors to keep easily track of new PRs.
Remove the numbers before publishing a new version :)</p>
<p>If there is a blog post covering the changes in more detail,
make sure to link it on the top of the release notes.
It would be a pity, if only a few people read the blog post
after our wonderful writers put so much effort into creating it.</p>
<h3 id="changelog-file">Changelog file</h3>
<p>Maintainers need to provide a changelog file for each release.
A changelog file is used by F-Droid to give a quick summary of the most important changes for a release.
This file is placed in the
<a href="https://github.com/teamnewpipe/newpipe/tree/dev/fastlane/metadata/android/en-US/changelogs"><code>/fastlane/metadata/android/en-US/changelogs</code></a>
directory and named <code>&lt;versionCode&gt;.txt</code> (whereas <code>&lt;versionCode&gt;</code> is the version code of the incoming release).
Changelog files <em>must not</em> exceed 500 bytes.
Be aware that the changelog is translated into multiple languages.
A changelog written in English which almost hits 500 bytes can hardly be translated completely within this limit.
This causes troubles for translators, because Weblate enforces the 500 bytes limit, too.
For this reason it is recommended to keep the changelog at 400 bytes.</p>
<p>When creating the changelog file be aware of changes which were done in the extractor as well.<br />
Before pushing the changelog to NewPipe's repo, ask other maintainers to review it.<br />
After pushing the changelog to NewPipe's GitHub repo, <a href="07_maintainers_view/#update-webalte">updating Weblate</a> is necessary.
This enables translators to work on localized versions of the changelog before a release is tagged and published.</p>
<h2 id="publish-on-f-droid">Publish on F-Droid</h2>
<p>NewPipe is and supports open source software.
For this reason, the preferred way to distribute the app is <a href="https://f-droid.org">F-Droid</a>.
F-Droid is a catalogue of FOSS apps and also comes with an Android client which handles app updates.
There are two ways to install NewPipe via F-Droid.</p>
<ol>
<li><strong>Through the main F-Droid repository</strong><br />
NewPipe's metadata file can be found in F-Droid's data repository on GitLab:
<a href="https://gitlab.com/fdroid/fdroiddata/-/blob/master/metadata/org.schabi.newpipe.yml">https://gitlab.com/fdroid/fdroiddata/-/blob/master/metadata/org.schabi.newpipe.yml</a><br />
This file is automatically updated by a bot when a new release is published on GitHub.
It can take a few days until all new apps on F-Droid are built, signed and published.<br />
<a href="https://f-droid.org/docs/Reproducible_Builds/">F-Droid also supports reproducible builds</a>.
Reproducible builds or deterministic builds allow someone else to retrieve the exact same binary
as we get when building the app (except the signing of course).<br />
When the reproducible build feature is enabled for an app in F-Droid, they compare their binary to one provided by the author.
If both are identical, F-Droid does not only publish the binary signed by themselves, but also the one signed by the author.<br />
Currently, NewPipe's builds are not deterministic, and we therefore cannot use that feature.
Once the builds are deterministic again, the following steps need to be done to publish a new version on F-Droid:<ol>
<li><a href="https://f-droid.org/docs/Installing_the_Server_and_Repo_Tools/">Install <code>fdroidserver</code> on your device</a>.</li>
<li>Clone the F-Droid Data repo from <code>https://gitlab.com/fdroid/fdroiddata</code></li>
<li>Add the new version to <code>metadata/org.schabi.newpipe.yml</code></li>
<li>Run <code>fdroid signatures /path/to/newpipe.apk</code> on the signed APK from within the repo.</li>
<li>Create a MR on GitLab.
An example commit containing all required changes can be found <a href="https://gitlab.com/fdroid/fdroiddata/-/commit/393bbb756d5bed4134eb147f411a9d9aa1d47386">here</a>.</li>
</ol>
</li>
<li><strong>Through NewPipe's F-Droid repository</strong><br />
F-Droid needs
NewPipe's own F-Droid repo is available at <a href="https://archive.newpipe.net/fdroid/repo/?fingerprint=E2402C78F9B97C6C89E97DB914A2751FDA1D02FE2039CC0897A462BDB57E7501">https://archive.newpipe.net/fdroid/repo</a>
It is updated and maintained by <a href="https://github.com/TheAssassin">@TheAssassin</a>.</li>
</ol>
</div>
</div>
@ -325,17 +454,18 @@ changes done to the app.</p>
</div>
<div class="rst-versions" role="note" aria-label="versions">
<span class="rst-current-version" data-toggle="rst-current-version">
<span><a href="../04_Run_changes_in_App/" style="color: #fcfcfc;">&laquo; Previous</a></span>
<span style="margin-left: 15px"><a href="../06_documentation/" style="color: #fcfcfc">Next &raquo;</a></span>
</span>
<span class="rst-current-version" data-toggle="rst-current-version">
<span><a href="../04_Run_changes_in_App/" style="color: #fcfcfc">&laquo; Previous</a></span>
<span><a href="../06_documentation/" style="color: #fcfcfc">Next &raquo;</a></span>
</span>
</div>
<script>var base_url = '..';</script>
<script src="../js/theme_extra.js" defer></script>
<script src="../js/theme.js" defer></script>
<script src="../search/main.js" defer></script>
<script defer>

23
06_documentation/index.html
View File

@ -31,7 +31,6 @@
<script src="../js/modernizr-2.8.3.min.js" defer></script>
<script src="../js/highlight.min.js"></script>
<script>hljs.initHighlightingOnLoad();</script>
</head>
<body class="wy-body-for-nav" role="document">
@ -45,7 +44,7 @@
<a href=".." class="icon icon-home"> NewPipe Documentation</a>
<div role="search">
<form id ="rtd-search-form" class="wy-form" action="../search.html" method="get">
<input type="text" name="q" placeholder="Search docs" title="Type search term here" />
<input type="text" name="q" placeholder="Search docs" title="Type search term here" />
</form>
</div>
</div>
@ -134,6 +133,7 @@
<hr/>
</div>
<div role="main">
<div class="section">
@ -222,17 +222,18 @@ or run <code>sudo pip3 install mkdocs</code> to install mkdocs systemwide. Last
</div>
<div class="rst-versions" role="note" aria-label="versions">
<span class="rst-current-version" data-toggle="rst-current-version">
<span><a href="../05_releasing/" style="color: #fcfcfc;">&laquo; Previous</a></span>
<span style="margin-left: 15px"><a href="../07_maintainers_view/" style="color: #fcfcfc">Next &raquo;</a></span>
</span>
<span class="rst-current-version" data-toggle="rst-current-version">
<span><a href="../05_releasing/" style="color: #fcfcfc">&laquo; Previous</a></span>
<span><a href="../07_maintainers_view/" style="color: #fcfcfc">Next &raquo;</a></span>
</span>
</div>
<script>var base_url = '..';</script>
<script src="../js/theme_extra.js" defer></script>
<script src="../js/theme.js" defer></script>
<script src="../search/main.js" defer></script>
<script defer>

64
07_maintainers_view/index.html
View File

@ -31,7 +31,6 @@
<script src="../js/modernizr-2.8.3.min.js" defer></script>
<script src="../js/highlight.min.js"></script>
<script>hljs.initHighlightingOnLoad();</script>
</head>
<body class="wy-body-for-nav" role="document">
@ -45,7 +44,7 @@
<a href=".." class="icon icon-home"> NewPipe Documentation</a>
<div role="search">
<form id ="rtd-search-form" class="wy-form" action="../search.html" method="get">
<input type="text" name="q" placeholder="Search docs" title="Type search term here" />
<input type="text" name="q" placeholder="Search docs" title="Type search term here" />
</form>
</div>
</div>
@ -96,6 +95,14 @@
</li>
<li class="toctree-l2"><a class="reference internal" href="#community">Community</a>
</li>
<li class="toctree-l2"><a class="reference internal" href="#managing-translations-via-weblate">Managing translations via Weblate</a>
<ul>
<li class="toctree-l3"><a class="reference internal" href="#update-weblate">Update Weblate</a>
</li>
<li class="toctree-l3"><a class="reference internal" href="#merge-changes-from-weblate-into-newpipe">Merge changes from Weblate into NewPipe</a>
</li>
</ul>
</li>
</ul>
</li>
</ul>
@ -128,6 +135,7 @@
<hr/>
</div>
<div role="main">
<div class="section">
@ -190,6 +198,43 @@ There also might be things that seem to not have any issues, but other things wi
<h3 id="community">Community</h3>
<p>When you talk to the community, stay friendly and respectful with good etiquette.
When you have a bad day, just don't go to GitHub (advice from our experience ;D ).</p>
<h3 id="managing-translations-via-weblate">Managing translations via Weblate</h3>
<p>NewPipe is translated via <a href="https://hosted.weblate.org/projects/newpipe">Weblate</a>.
There are two different components which are open for translation:</p>
<ul>
<li>The app <a href="https://hosted.weblate.org/projects/newpipe/strings/"><code>strings</code></a>.</li>
<li>The fastlane <a href="https://hosted.weblate.org/projects/newpipe/metadata/">metadata</a>;
this includes the F-Droid store description and changelogs.</li>
</ul>
<p>Maintainers can access more options to handle Weblate via the
<a href="https://hosted.weblate.org/projects/newpipe/#repository">Manage &gt; Repository Maintenance</a> button
or via the <a href="https://docs.weblate.org/en/latest/wlc.html#wlc">Weblate CLI</a>. These options include
basic access to Git operations like commit and rebase
as well as locking Weblate to prevent further changes to translations.</p>
<p><a href="https://hosted.weblate.org/projects/newpipe/#repository"><img alt="Weblate Web Interface" src="../img/weblate.png" /></a>
<code>HINT: When updating Weblate via the web interface, please use the "Update &gt; Rebase" option.</code></p>
<h4 id="update-weblate">Update Weblate</h4>
<p>Weblate is based on NewPipe's <code>dev</code> branch and is configured to automatically update its repository to be in sync with NewPipe.
However, Weblate does not update its branch often, therefore it is better to update it manually after changing strings in NewPipe.</p>
<p>To do thus manually, commit the Weblate changes and rebase the repository.
Sometimes conflicts need to be resoled while rebasing the repository.
Conflicts need to be addressed ASAP, because Weblate is automatically locked once conflicts occur.
To do so, <a href="#merge-changes-from-weblate-into-newpipe">merge the changes from Weblate into NewPipe</a>.
If Weblate does not recognize the new commit by itself, ask Weblate to rebase once more.
Weblate unlocks the translations when all conflicts are resolved and no errors are detected.</p>
<h4 id="merge-changes-from-weblate-into-newpipe">Merge changes from Weblate into NewPipe</h4>
<p>Weblate does not push the translation changes to NewPipe automatically.
Doing this manually, allows the maintainers to do a quick review of the changes.</p>
<p>Before merging weblate changes into NewPipe, make sure to commit all Weblate changes and
lock the Weblate to prevent modifications while you update Weblate.
To merge the changes into NewPipe, checkout Weblate's <code>dev</code> branch.
You have read access to Weblate's repository via <code>https://hosted.weblate.org/git/newpipe/strings/</code>.
If there are conflicts when rebasing weblate, resolve them.</p>
<p>Check the following things:
- Is there a translation for a new language? If yes, <a href="https://github.com/TeamNewPipe/NewPipe/pull/5721">register the language with the app's langauge selector</a>
- Use <code>Analyse &gt; Inspect Code</code> in Android Studio to find unused strings and potential bugs introduced by Weblate.
Pay attention to plurals in Asian languages. They are broken by Weblate on a regular basis.</p>
<p>Push the changes to NewPipe's <code>dev</code> branch, <a href="#update-weblate">update Weblate</a> and unlock it.</p>
</div>
</div>
@ -221,15 +266,16 @@ When you have a bad day, just don't go to GitHub (advice from our experience ;D
</div>
<div class="rst-versions" role="note" aria-label="versions">
<span class="rst-current-version" data-toggle="rst-current-version">
<span><a href="../06_documentation/" style="color: #fcfcfc;">&laquo; Previous</a></span>
</span>
<span class="rst-current-version" data-toggle="rst-current-version">
<span><a href="../06_documentation/" style="color: #fcfcfc">&laquo; Previous</a></span>
</span>
</div>
<script>var base_url = '..';</script>
<script src="../js/theme_extra.js" defer></script>
<script src="../js/theme.js" defer></script>
<script src="../search/main.js" defer></script>
<script defer>

19
404.html
View File

@ -14,13 +14,12 @@
<link rel="stylesheet" href="/css/theme.css" />
<link rel="stylesheet" href="/css/theme_extra.css" />
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/highlight.js/9.12.0/styles/github.min.css" />
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/highlight.js/10.5.0/styles/github.min.css" />
<script src="/js/jquery-2.1.1.min.js" defer></script>
<script src="/js/modernizr-2.8.3.min.js" defer></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/highlight.js/9.12.0/highlight.min.js"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/highlight.js/10.5.0/highlight.min.js"></script>
<script>hljs.initHighlightingOnLoad();</script>
</head>
<body class="wy-body-for-nav" role="document">
@ -34,7 +33,7 @@
<a href="/." class="icon icon-home"> NewPipe Documentation</a>
<div role="search">
<form id ="rtd-search-form" class="wy-form" action="//search.html" method="get">
<input type="text" name="q" placeholder="Search docs" title="Type search term here" />
<input type="text" name="q" placeholder="Search docs" title="Type search term here" />
</form>
</div>
</div>
@ -103,6 +102,7 @@
<hr/>
</div>
<div role="main">
<div class="section">
@ -135,13 +135,14 @@
</div>
<div class="rst-versions" role="note" aria-label="versions">
<span class="rst-current-version" data-toggle="rst-current-version">
</span>
<span class="rst-current-version" data-toggle="rst-current-version">
</span>
</div>
<script>var base_url = '/';</script>
<script src="/js/theme_extra.js" defer></script>
<script src="/js/theme.js" defer></script>
<script src="/search/main.js" defer></script>
<script defer>

53
css/theme_extra.css
View File

@ -122,7 +122,7 @@ form .search-query {
/*
* Account for wide tables which go off the side.
* Override borders to avoid wierdness on narrow tables.
* Override borders to avoid weirdness on narrow tables.
*
* https://github.com/mkdocs/mkdocs/issues/834
* https://github.com/mkdocs/mkdocs/pull/1034
@ -138,3 +138,54 @@ td, th {
border: 1px solid #e1e4e5 !important; /* csslint allow: important */
border-collapse: collapse;
}
/*
* Without the following amendments, the navigation in the theme will be
* slightly cut off. This is due to the fact that the .wy-nav-side has a
* padding-bottom of 2em, which must not necessarily align with the font-size of
* 90 % on the .rst-current-version container, combined with the padding of 12px
* above and below. These amendments fix this in two steps: First, make sure the
* .rst-current-version container has a fixed height of 40px, achieved using
* line-height, and then applying a padding-bottom of 40px to this container. In
* a second step, the items within that container are re-aligned using flexbox.
*
* https://github.com/mkdocs/mkdocs/issues/2012
*/
.wy-nav-side {
padding-bottom: 40px;
}
/*
* The second step of above amendment: Here we make sure the items are aligned
* correctly within the .rst-current-version container. Using flexbox, we
* achieve it in such a way that it will look like the following:
*
* [No repo_name]
* Next >> // On the first page
* << Previous Next >> // On all subsequent pages
*
* [With repo_name]
* <repo_name> Next >> // On the first page
* <repo_name> << Previous Next >> // On all subsequent pages
*
* https://github.com/mkdocs/mkdocs/issues/2012
*/
.rst-versions .rst-current-version {
padding: 0 12px;
display: flex;
font-size: initial;
justify-content: space-between;
align-items: center;
line-height: 40px;
}
/*
* Please note that this amendment also involves removing certain inline-styles
* from the file ./mkdocs/themes/readthedocs/versions.html.
*
* https://github.com/mkdocs/mkdocs/issues/2012
*/
.rst-current-version span {
flex: 1;
text-align: center;
}

BIN
img/weblate.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 105 KiB

23
index.html
View File

@ -31,7 +31,6 @@
<script src="js/modernizr-2.8.3.min.js" defer></script>
<script src="./js/highlight.min.js"></script>
<script>hljs.initHighlightingOnLoad();</script>
</head>
<body class="wy-body-for-nav" role="document">
@ -45,7 +44,7 @@
<a href="." class="icon icon-home"> NewPipe Documentation</a>
<div role="search">
<form id ="rtd-search-form" class="wy-form" action="./search.html" method="get">
<input type="text" name="q" placeholder="Search docs" title="Type search term here" />
<input type="text" name="q" placeholder="Search docs" title="Type search term here" />
</form>
</div>
</div>
@ -120,6 +119,7 @@
<hr/>
</div>
<div role="main">
<div class="section">
@ -163,15 +163,16 @@ It focuses on making it possible for the creator of a scraper for a streaming se
</div>
<div class="rst-versions" role="note" aria-label="versions">
<span class="rst-current-version" data-toggle="rst-current-version">
<span style="margin-left: 15px"><a href="00_Prepare_everything/" style="color: #fcfcfc">Next &raquo;</a></span>
</span>
<span class="rst-current-version" data-toggle="rst-current-version">
<span><a href="00_Prepare_everything/" style="color: #fcfcfc">Next &raquo;</a></span>
</span>
</div>
<script>var base_url = '.';</script>
<script src="js/theme_extra.js" defer></script>
<script src="js/theme.js" defer></script>
<script src="search/main.js" defer></script>
<script defer>
@ -184,6 +185,6 @@ It focuses on making it possible for the creator of a scraper for a streaming se
</html>
<!--
MkDocs version : 1.1.2
Build Date UTC : 2020-08-13 00:02:52.633498+00:00
MkDocs version : 1.2.3
Build Date UTC : 2021-10-20 23:09:50.015755+00:00
-->

8
js/theme_extra.js Normal file
View File

@ -0,0 +1,8 @@
/*
* Assign 'docutils' class to tables so styling and
* JavaScript behavior is applied.
*
* https://github.com/mkdocs/mkdocs/issues/2028
*/
$('div.rst-content table').addClass('docutils');

17
search.html
View File

@ -24,7 +24,6 @@
<script src="./js/modernizr-2.8.3.min.js" defer></script>
<script src="./js/highlight.min.js"></script>
<script>hljs.initHighlightingOnLoad();</script>
</head>
<body class="wy-body-for-nav" role="document">
@ -38,7 +37,7 @@
<a href="./." class="icon icon-home"> NewPipe Documentation</a>
<div role="search">
<form id ="rtd-search-form" class="wy-form" action="./search.html" method="get">
<input type="text" name="q" placeholder="Search docs" title="Type search term here" />
<input type="text" name="q" placeholder="Search docs" title="Type search term here" />
</form>
</div>
</div>
@ -107,6 +106,7 @@
<hr/>
</div>
<div role="main">
<div class="section">
@ -118,7 +118,7 @@
<input name="q" id="mkdocs-search-query" type="text" class="search_input search-query ui-autocomplete-input" placeholder="Search the Docs" autocomplete="off" autofocus title="Type search term here">
</form>
<div id="mkdocs-search-results" class="search-results">
<div id="mkdocs-search-results" class="search-results" data-no-results-text="No results found">
Searching...
</div>
@ -146,13 +146,14 @@
</div>
<div class="rst-versions" role="note" aria-label="versions">
<span class="rst-current-version" data-toggle="rst-current-version">
</span>
<span class="rst-current-version" data-toggle="rst-current-version">
</span>
</div>
<script>var base_url = '.';</script>
<script src="./js/theme_extra.js" defer></script>
<script src="./js/theme.js" defer></script>
<script src="./search/main.js" defer></script>
<script defer>

34
search/lunr.js
View File

@ -1,6 +1,6 @@
/**
* lunr - http://lunrjs.com - A bit like Solr, but much smaller and not as bright - 2.3.8
* Copyright (C) 2019 Oliver Nightingale
* lunr - http://lunrjs.com - A bit like Solr, but much smaller and not as bright - 2.3.9
* Copyright (C) 2020 Oliver Nightingale
* @license MIT
*/
@ -54,10 +54,10 @@ var lunr = function (config) {
return builder.build()
}
lunr.version = "2.3.8"
lunr.version = "2.3.9"
/*!
* lunr.utils
* Copyright (C) 2019 Oliver Nightingale
* Copyright (C) 2020 Oliver Nightingale
*/
/**
@ -177,7 +177,7 @@ lunr.FieldRef.prototype.toString = function () {
}
/*!
* lunr.Set
* Copyright (C) 2019 Oliver Nightingale
* Copyright (C) 2020 Oliver Nightingale
*/
/**
@ -211,8 +211,8 @@ lunr.Set.complete = {
return other
},
union: function (other) {
return other
union: function () {
return this
},
contains: function () {
@ -389,7 +389,7 @@ lunr.Token.prototype.clone = function (fn) {
}
/*!
* lunr.tokenizer
* Copyright (C) 2019 Oliver Nightingale
* Copyright (C) 2020 Oliver Nightingale
*/
/**
@ -465,7 +465,7 @@ lunr.tokenizer = function (obj, metadata) {
lunr.tokenizer.separator = /[\s\-]+/
/*!
* lunr.Pipeline
* Copyright (C) 2019 Oliver Nightingale
* Copyright (C) 2020 Oliver Nightingale
*/
/**
@ -732,7 +732,7 @@ lunr.Pipeline.prototype.toJSON = function () {
}
/*!
* lunr.Vector
* Copyright (C) 2019 Oliver Nightingale
* Copyright (C) 2020 Oliver Nightingale
*/
/**
@ -929,7 +929,7 @@ lunr.Vector.prototype.toJSON = function () {
/* eslint-disable */
/*!
* lunr.stemmer
* Copyright (C) 2019 Oliver Nightingale
* Copyright (C) 2020 Oliver Nightingale
* Includes code from - http://tartarus.org/~martin/PorterStemmer/js.txt
*/
@ -1151,7 +1151,7 @@ lunr.stemmer = (function(){
lunr.Pipeline.registerFunction(lunr.stemmer, 'stemmer')
/*!
* lunr.stopWordFilter
* Copyright (C) 2019 Oliver Nightingale
* Copyright (C) 2020 Oliver Nightingale
*/
/**
@ -1316,7 +1316,7 @@ lunr.stopWordFilter = lunr.generateStopWordFilter([
lunr.Pipeline.registerFunction(lunr.stopWordFilter, 'stopWordFilter')
/*!
* lunr.trimmer
* Copyright (C) 2019 Oliver Nightingale
* Copyright (C) 2020 Oliver Nightingale
*/
/**
@ -1343,7 +1343,7 @@ lunr.trimmer = function (token) {
lunr.Pipeline.registerFunction(lunr.trimmer, 'trimmer')
/*!
* lunr.TokenSet
* Copyright (C) 2019 Oliver Nightingale
* Copyright (C) 2020 Oliver Nightingale
*/
/**
@ -1827,7 +1827,7 @@ lunr.TokenSet.Builder.prototype.minimize = function (downTo) {
}
/*!
* lunr.Index
* Copyright (C) 2019 Oliver Nightingale
* Copyright (C) 2020 Oliver Nightingale
*/
/**
@ -1994,7 +1994,7 @@ lunr.Index.prototype.query = function (fn) {
*/
var clause = query.clauses[i],
terms = null,
clauseMatches = lunr.Set.complete
clauseMatches = lunr.Set.empty
if (clause.usePipeline) {
terms = this.pipeline.runString(clause.term, {
@ -2319,7 +2319,7 @@ lunr.Index.load = function (serializedIndex) {
}
/*!
* lunr.Builder
* Copyright (C) 2019 Oliver Nightingale
* Copyright (C) 2020 Oliver Nightingale
*/
/**

6
search/main.js
View File

@ -37,7 +37,11 @@ function displayResults (results) {
search_results.insertAdjacentHTML('beforeend', html);
}
} else {
search_results.insertAdjacentHTML('beforeend', "<p>No results found</p>");
var noResultsText = search_results.getAttribute('data-no-results-text');
if (!noResultsText) {
noResultsText = "No results found";
}
search_results.insertAdjacentHTML('beforeend', '<p>' + noResultsText + '</p>');
}
}

2
search/search_index.json
View File

File diff suppressed because one or more lines are too long

3
search/worker.js
View File

@ -44,6 +44,9 @@ function onJSONLoaded () {
if (lang.length > 1) {
scriptsToLoad.push('lunr.multi.js');
}
if (lang.includes("ja") || lang.includes("jp")) {
scriptsToLoad.push('tinyseg.js');
}
for (var i=0; i < lang.length; i++) {
if (lang[i] != 'en') {
scriptsToLoad.push(['lunr', lang[i], 'js'].join('.'));

81
sitemap.xml
View File

@ -1,39 +1,48 @@
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"><url>
<loc>None</loc>
<lastmod>2020-08-13</lastmod>
<changefreq>daily</changefreq>
</url><url>
<loc>None</loc>
<lastmod>2020-08-13</lastmod>
<changefreq>daily</changefreq>
</url><url>
<loc>None</loc>
<lastmod>2020-08-13</lastmod>
<changefreq>daily</changefreq>
</url><url>
<loc>None</loc>
<lastmod>2020-08-13</lastmod>
<changefreq>daily</changefreq>
</url><url>
<loc>None</loc>
<lastmod>2020-08-13</lastmod>
<changefreq>daily</changefreq>
</url><url>
<loc>None</loc>
<lastmod>2020-08-13</lastmod>
<changefreq>daily</changefreq>
</url><url>
<loc>None</loc>
<lastmod>2020-08-13</lastmod>
<changefreq>daily</changefreq>
</url><url>
<loc>None</loc>
<lastmod>2020-08-13</lastmod>
<changefreq>daily</changefreq>
</url><url>
<loc>None</loc>
<lastmod>2020-08-13</lastmod>
<changefreq>daily</changefreq>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<url>
<loc>None</loc>
<lastmod>2021-10-20</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>None</loc>
<lastmod>2021-10-20</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>None</loc>
<lastmod>2021-10-20</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>None</loc>
<lastmod>2021-10-20</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>None</loc>
<lastmod>2021-10-20</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>None</loc>
<lastmod>2021-10-20</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>None</loc>
<lastmod>2021-10-20</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>None</loc>
<lastmod>2021-10-20</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>None</loc>
<lastmod>2021-10-20</lastmod>
<changefreq>daily</changefreq>
</url>
</urlset>

BIN
sitemap.xml.gz
View File

Binary file not shown.