Deployed 01cfd0f
with MkDocs version: 1.0.4
This commit is contained in:
parent
fdf16e04ee
commit
2c5e8bfa88
|
@ -155,20 +155,24 @@ god as possible. Our whole release cycle is therefore designed around this issue
|
||||||
and a version that fixes an issue that occurred because Youtube (or some other service) suddenly changed their website (mostly call this a shutdown).
|
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>
|
Lets first have a look how a regular release work, and then how the hotfix release work.</p>
|
||||||
<h2 id="regular-releases">Regular releases</h2>
|
<h2 id="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
|
<p>Regular releases are normal releases like they are done 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
|
<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>
|
branch with a stable/releasable version.</p>
|
||||||
<h3 id="feature-branching">Feature branching</h3>
|
<h3 id="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>.
|
<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 adding something to it.
|
||||||
This ensures that also the dev version works as good a possible.
|
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>
|
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><img alt="feature_branching" src="../img/feature_branch.svg" /></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 to each other.
|
||||||
|
If a change is done on the API to the extractor make sure that frontend is being made compatible to 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 as well. 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>
|
<h3 id="merging-featuresbugfixes">Merging features/bugfixes</h3>
|
||||||
<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>.
|
<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.
|
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 prefare code 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>
|
So in short: cool function but bad code -> no merge. We should focus on leaving the code as clean as possible.</p>
|
||||||
<p><img alt="merge_feature_into_dev" src="../img/merge_into_dev.svg" /></p>
|
<p><img alt="merge_feature_into_dev" src="../img/merge_into_dev.svg" /></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>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. <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 merged the new feature into the dev branch he should add the title of the pullrequest or a summary of the changes into the <a href="#release-notes">release note</a>.</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 <a href="#release-notes">release note</a>.</p>
|
||||||
<h3 id="creating-a-new-release">Creating a new release</h3>
|
<h3 id="creating-a-new-release">Creating a new release</h3>
|
||||||
<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.
|
<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.
|
||||||
|
|
|
@ -137,11 +137,11 @@
|
||||||
|
|
||||||
<h1 id="welcome-to-the-newpipe-documentation">Welcome to the NewPipe Documentation.</h1>
|
<h1 id="welcome-to-the-newpipe-documentation">Welcome to the NewPipe Documentation.</h1>
|
||||||
<p><img width=150 src="https://raw.githubusercontent.com/TeamNewPipe/NewPipe/dev/assets/new_pipe_icon_5.png"/></p>
|
<p><img width=150 src="https://raw.githubusercontent.com/TeamNewPipe/NewPipe/dev/assets/new_pipe_icon_5.png"/></p>
|
||||||
<p>This site is/should be a beginner friendly tutorial and documentation for people who want to use, or write services for the <a href="https://github.com/TeamNewPipe/NewPipeExtractor">NewPipe Extractor</a>.
|
<p>This site is/should be a beginner friendly tutorial and documentation for people who want to use, or write services for the <a href="https://github.com/TeamNewPipe/NewPipeExtractor">NewPipe Extractor</a> however it does also contain several notes about how to maintain NewPipe.
|
||||||
It is an addition to our auto generated <a href="https://teamnewpipe.github.io/NewPipeExtractor/javadoc/">jdoc documentation</a>.</p>
|
It is an addition to our auto generated <a href="https://teamnewpipe.github.io/NewPipeExtractor/javadoc/">jdoc documentation</a>.</p>
|
||||||
<p>Please be aware that it is also in an early state, so help and <a href="https://github.com/TeamNewPipe/documentation/issues">feedback</a> is always welcome :D</p>
|
<p>Please be aware that it is also in an early state, so help and <a href="https://github.com/TeamNewPipe/documentation/issues">feedback</a> is always welcome :D</p>
|
||||||
<h2 id="introduction">Introduction</h2>
|
<h2 id="introduction">Introduction</h2>
|
||||||
<p>The NewPipeExtractor is a Java framework for scraping video platform websites in a way that they can be accessed like a normal API. The extractor is the core of the popular YouTube and streaming App <a href="https://newpipe.schabi.org">NewPipe</a> for android, however it's system independent and also available for other platforms. </p>
|
<p>The NewPipeExtractor is a Java framework for scraping video platform websites in a way that they can be accessed like a normal API. The extractor is the core of the popular YouTube and streaming App <a href="https://newpipe.schabi.org">NewPipe</a> for android, however it's system independent and also available for other platforms as well. </p>
|
||||||
<p>The beauty behind this framework is it takes care of the extracting process, error handling etc., so you can take care about what is important: Scraping the website.
|
<p>The beauty behind this framework is it takes care of the extracting process, error handling etc., so you can take care about what is important: Scraping the website.
|
||||||
It focuses on making it possible for the creator of a scraper for a streaming service to create the best outcome with the least amount of written code.</p>
|
It focuses on making it possible for the creator of a scraper for a streaming service to create the best outcome with the least amount of written code.</p>
|
||||||
|
|
||||||
|
@ -192,5 +192,5 @@ It focuses on making it possible for the creator of a scraper for a streaming se
|
||||||
|
|
||||||
<!--
|
<!--
|
||||||
MkDocs version : 1.0.4
|
MkDocs version : 1.0.4
|
||||||
Build Date UTC : 2019-02-21 14:22:06
|
Build Date UTC : 2019-02-21 14:56:42
|
||||||
-->
|
-->
|
||||||
|
|
File diff suppressed because one or more lines are too long
BIN
sitemap.xml.gz
BIN
sitemap.xml.gz
Binary file not shown.
Loading…
Reference in New Issue