diff --git a/assets/feature_branch.dia b/assets/feature_branch.dia new file mode 100644 index 0000000..8712d63 Binary files /dev/null and b/assets/feature_branch.dia differ diff --git a/assets/release_branch.dia b/assets/release_branch.dia deleted file mode 100644 index 149a9d4..0000000 Binary files a/assets/release_branch.dia and /dev/null differ diff --git a/docs/05_releasing.md b/docs/05_releasing.md index 3807f10..16b8e8d 100644 --- a/docs/05_releasing.md +++ b/docs/05_releasing.md @@ -26,9 +26,9 @@ For development the __dev__ branch is used. Pushing to __dev__ directly however 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 __fork__ the dev branch and develop the changes in his own branch (this is called feature branching). -![feature_branching](img/release_branch.svg) +![feature_branching](img/feature_branch.svg) -### Merching features/bugfixes +### Merging features/bugfixes After being done with the feature one should open up a __Pull Reuqest__ to the dev branch here a maintainer can do __Code review__ and __Quality Assurance (QA)__. 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. @@ -36,10 +36,19 @@ So in short: cool function but bad code -> no merge. We should focus on leaving ![merge_feature_into_dev](img/merge_into_dev.svg) -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. +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. + +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 [release note](#release-notes). ### Creating a new release +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. + +1. Fork the __dev__ branch into a new __release_x.y.z__ branch. +2. Increase the [version number](#versioning) +3. Copy the [release note](#release-notes) from the github version draft into the corresponding fastlane file (see [release note](#release-notes)). +4. Open up a pull request form the new __release_x.y.z__ branch into the __master__ branch. + ### Releasing ## Hotfix releases @@ -49,3 +58,35 @@ At best you as a maintainer should build the app and put the signed apk into the ### Fix branch ### Releasing + +## Versioning + +Versioning NewPipe is simple. + +- __Major__: The __major__ 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 ¯\\\_(ツ)\_/¯ . +- __Minor__: The __minor__ version number (the number after the first dot) will be increased if there is a major feature added to the app. +- __Small Minor__: 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. + + +#### Versioning the extractor + +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. + +#### Version code +In android an app can also have a [versionCode](https://developer.android.com/studio/publish/versioning). This code is a `long integer` 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. + +## Release notes +Release notes should give the user an idea of what was changed on the app. The release nodes for NewPipe are stored in the [github draft for a new release](https://github.com/TeamNewPipe/NewPipe/releases/tag/v0.14.0). When a maintainer wants to add change to the release note, but there is no draft for a new version he should create one. + +Changes can be categorized into three types. + +- __New__: New features that god added to the app. +- __Improved__: Improvements to the app, or already existing features +- __Fixes__: Bugfixes + +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 +`.txt` (whereas `` needs to be the version code of the comming release). This file must be stored in the direcotry [`/fastlane/metadata/android/en-US/changelogs`](https://github.com/teamnewpipe/newpipe/tree/dev/fastlane/metadata/android/en-US/changelogs). This way fdroid will later be able to show the +changes done on the app. diff --git a/docs/img/release_branch.svg b/docs/img/feature_branch.svg similarity index 74% rename from docs/img/release_branch.svg rename to docs/img/feature_branch.svg index ba3c833..7858eec 100644 --- a/docs/img/release_branch.svg +++ b/docs/img/feature_branch.svg @@ -8,14 +8,14 @@ xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd" xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape" width="210" - height="310.22198" - viewBox="385 95 111.125 157.21394" + height="300" + viewBox="385 95 104.17968 152.03365" version="1.1" - id="svg31" - sodipodi:docname="release_branch.svg" + id="svg39" + sodipodi:docname="feature_branch.svg" inkscape:version="0.92.3 (2405546, 2018-03-11)"> + id="metadata45"> @@ -27,7 +27,7 @@ + id="defs43" /> + inkscape:current-layer="svg39" /> + transform="matrix(0.6187154,0,0,0.6187154,144.56047,34.721636)"> release_xyz + x="459.65701" + y="107.209" + id="tspan18">feature_xyz + + + + + +