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
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>
<h2id="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
<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>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
<p>After finishing a feature, one should open up a <strong>Pull Reuqest</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>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 <ahref="#release-notes">release notes</a>.</p>
<h3id="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>
<li>Increase the <ahref="#version-nomenclature">version number</a></li>
<li>Merge <ahref="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 <ahref="#release-notes">release notes</a> from the GitHub version draft into the corresponding fastlane file (see <ahref="#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_<versionNumber>_RC1.apk</code>.
<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_<versionNumber>_RC2.apk</code> etc. <em>Don't update the actual version number. :P</em></p>
<p>Once the glorious day of all days has come, and you fulfill the ceremony of releasing.
After going through the release procedure of <ahref="#create_a_new_release">creating a new release</a> and maybe a few <ahref="#quickfixes">quickfixes</a> on the new release,
<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>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>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.
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 ¯\_(ツ)_/¯.
<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>
<h4id="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>
<h4id="version-code">Version Code</h4>
<p>In Android, an app can also have a <ahref="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>
<h2id="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 <ahref="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>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><versionCode>.txt</code> (whereas <code><versionCode></code> needs to be the version code of the incoming release). This file must be stored in the directory <ahref="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
<ahref="../04_Run_changes_in_App/"class="btn btn-neutral"title="Testing Your Changes in the App"><spanclass="icon icon-circle-arrow-left"></span> Previous</a>
Built with <ahref="http://www.mkdocs.org">MkDocs</a> using a <ahref="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <ahref="https://readthedocs.org">Read the Docs</a>.
