<h1id="releasing-a-new-newpipe-version">Releasing a new NewPipe version</h1>
<p>This site is ment for those who want to maintain NewPipe, or just want to know how releasing work.</p>
<p><imgalt="one does not simply push to master"src="../img/onedoes.jpg"/></p>
<h2id="difference-between-regular-and-hotfix-release">Difference between regular and hotfix release</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 brake instantly when Youtube changes something.
We can not know when this happen therefore we need to be prepared when it happens, and at lease reduce our downtime as
god as possible. Our whole release cycle is therefore designed around this issue.</p>
<p>So there is a difference between a release that is meant to introduce new features or fix minor bugs,
and a version that fixes an issue that occurred because Youtube (or some other service) suddenly changed their website (mostly call this a shutdown).
Lets first have a look how a regular release work, and then how the hotfix release work.</p>
<h2id="regular-releases">Regular releases</h2>
<p>Regular releases are normal releases like they are done like in any other app. Releases are always stored on <strong>master</strong> branch. By means the latest commit on
<strong>master</strong> is always equal to the current releases. No development is done on master. This ensures that we always have one
branch with a stable/releasable version.</p>
<h3id="feature-branching">Feature branching</h3>
<p>For development the <strong>dev</strong> branch is used. Pushing to <strong>dev</strong> directly however is also not allowed since QA and testing should be done before pushing to <strong>dev</strong>.
This ensures that also the dev version works as good a possible.
So in order to change something on the app one may want to <strong>fork</strong> the dev branch and develop the changes in his own branch (this is called feature branching).</p>
<p>After being done with the feature one should open up a <strong>Pull Reuqest</strong> to the dev branch 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 corrosion or code shifting can be prevented. Please also preface core quality over functionality.
So in short: cool function but bad code -> no merge. We should focus on leaving the code as clean as possible.</p>
<p>At best you as a maintainer should build the app and put the signed apk into the description of that new pullrequest. This way other people can test the feature/bugfix and therefore help with QA.</p>
<p>After the maintainer merged the new feature into the dev branch he should add the title of the pullrequest or a summary of the changes into the <ahref="#release-notes">release note</a>.</p>
<p>Once there are enough features together, and the maintainer feels like releasing he should create a new release. Here is a list of things he will want to do then.
Be aware of the rule that a release should never be done on a frieday. For NewPipe this mean don't do a release if you don't have time for it!!!</p>
<li>Fork the <strong>dev</strong> branch into a new <strong>release_x.y.z</strong> branch.</li>
<li>Increase the <ahref="#versioning">version number</a></li>
<li>Copy the <ahref="#release-notes">release note</a> from the github version draft into the corresponding fastlane file (see <ahref="#release-notes">release note</a>).</li>
<li>Open up a pullrequest 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 Pullrequest. The reason for opening an issue is that from my perception more people are reading issues then they read pullrequests. 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>.
Zip it and post it into the head of the release issue. This way other people can test the release candidate.</li>
<li>Test and QA the new version with the help of other people</li>
<li>Leave the PR open for a few days and advertise people to help testing.</li>
<p>While being in release phase no new pullrequests 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>
<h3id="quckfixes">Quckfixes</h3>
<p>When issuing a new release you will most likely encounter new bugs. These bugs are called <strong>regressions</strong> as they where not there before.
If you notice 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 (people who have write access to the release branch) have to be aware that they might be required to fix regressions so plan your release on a time when
you have time for coding. Do not introduce new features while being in release phase.</p>
<p>When you have pushed a quickfix you will want to updated the <strong>release candidate</strong> you put into the <strong>issue</strong> corresponding to the <strong>release pull request</strong>.
Increase the version number in the filename of the Release candidate. e.g. <code>NewPipe_<versionNumber>_RC2.apk</code> etc. <em>Don't update the actuall version number however :P</em>.</p>
<p>Once the glories day of all days has come, and you feel like fulfilling the ceremony of releasing. This is what you will want to do.
After going through the release procedure of having <ahref="#create_a_new_release">created a new release</a> and maybe having done <ahref="#quickfixes">quickfixes</a> on the new release,
you will want to do these steps:</p>
<ol>
<li>Hit merge Pullreqest</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 <imgalt="draft_name"src="../img/draft_name.png"/></li>
<li>Make sure to not have forgotten enything</li>
<li>Hit <code>Publish Release</code></li>
<li>Rebase quickfix changes back into <strong>dev</strong> if quickfixes where made</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 increasing this number to 1 once we can ensure that NewPipe runs stable (part of which this documentation should help). After this (2 and beyond) 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 increased 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 increased if there are just smaller bug fixes or features added to the app.</li>
</ul>
<h4id="versioning-the-extractor">Versioning the extractor</h4>
<p>The extractor is always released together with the app, therefore the version number of the extractor is the same as the one of the app.</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 increased by any value to show a device that a new version is there.
For NewPipe the version code will be increased 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 fdroid build server.</p>
<h2id="release-notes">Release notes</h2>
<p>Release notes should give the user an idea of what was changed on 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 change to the release note, but there is no draft for a new version he should create one.</p>
<p>Changes can be categorized into three types.</p>
<ul>
<li><strong>New</strong>: New features that god added to the app.</li>
<li><strong>Improved</strong>: Improvements to the app, or already existing features</li>
<li><strong>Fixes</strong>: Bugfixes</li>
</ul>
<p>When releasing a new version of NewPipe, before actually hitting release the maintainer should copy the release note 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 comming release). This file must be stored in the direcotry <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 fdroid will later be able to show the
<ahref="../04_Run_changes_in_App/"class="btn btn-neutral"title="Run the changes in the App"><spanclass="icon icon-circle-arrow-left"></span> Previous</a>
</div>
<hr/>
<divrole="contentinfo">
<!-- Copyright etc -->
</div>
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>.
