Releasing a New NewPipe Version
This site is meant for those who want to maintain NewPipe, or just want to know how releasing works.
@@ -215,70 +199,12 @@ and different devices like phones, tablets and TVs.
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
release notes.
-
Creating a New Release
+
Normal Releases
Once there are enough changes, and the maintainers believe that NewPipe is ready
for a new version, they should prepare a new release.
Be aware of the rule that a release should never be done on a Friday.
For NewPipe, this means: Don't do a release if you don't have time for it!!!
-
By following the steps listed below, you can publish a stable version of NewPipe:
-
-- Merge the translations from Weblate into NewPipe.
-- Update your local dev branch and create a changelog file.
- Make sure to push the changes and update Weblate.
-- In your local NewPipe repo, fork the dev branch into a new release/x.y.z branch.
-- Increase the version number and update the version code in the
build.gradle file.
-- Open a pull request form the new release/x.y.z branch into the master branch.
-- 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.
-- Create signed release and debug APKs of the release branch using the
releaseCandidate and debug build types.
- Name the build apk files NewPipe_<versionCode>_RC1.apk and NewPipe_<versionCode>_debug_RC1.apk.
- 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.
-- Test and QA the new version with the help of others. Keep the PR and issue open for a few days
-
-
New features can be merged into dev while the release candidate is tested.
-PRs which aim to fix regressions of the upcoming release need to target the release/x.y.z branch.
-Read Quickfixes for more info.
-
The changelogs are translated during the test phase.
-Therefore, the translations need to be merged from Weblate once more.
-The translation commit is cherry-picked into the release branch.
-
Once testing is done and the release branch does not contain critical regressions, and you think the update is ready,
-proceed with releasing the new version.
-
Quickfixes
-
When issuing a new release, you will most likely encounter bugs
-that might not have existed in previous versions.
-These are called regressions.
-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.
-
When you have pushed a quickfix, you need to provide an updated release candidate.
-Increment the version number in the filename of the release candidate. e.g. NewPipe_<versionNumber>_RC2.apk etc.
-Don't update the actual version number. :P
-
-
Releasing
-
Once the glorious day of all days has come, and you fulfill the ceremony of releasing.
-After going through the release procedure of creating a new release
-and maybe a few quickfixes on the new release,
-this is what you should do when releasing:
-
-- Click "Merge Pull Request".
-- Checkout the master branch locally and create an unsigned APK.
-- Send this APK to TheAssassin for signing and publishing in an encrypted and signed E-Mail. He'll check your APK, too.
-- Once you received a signed APK, upgrade the version on your device and look for any crashes and regressions.
-- In the GitHub releases section, make sure the draft name equals the tag name.
-- Add the signed APK to the draft.
-- Make sure to not have forgotten anything.
-- Click "Publish Release".
-- Publish the new version on F-Droid.
-- Merge master into dev or fast-forward if possible. Push.
-- Update the changelog for the website.
-
-
+
By following the steps listed in Release instructions, you can publish a stable version of NewPipe.
Hotfix Releases
As aforementioned, NewPipe heavily relies on external components and might break at a random point of time.
@@ -298,7 +224,7 @@ Of course, you are not allowed to push to master directly,
so you need to create a hotfix branch.
If someone else is pushing a hotfix into master, and it works this can be considered as hotfix branch as well.
-
Releasing
+
Releasing
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.
@@ -392,7 +318,7 @@ This causes troubles for translators, because Weblate enforces the 500 bytes lim
For this reason it is recommended to keep the changelog at 400 bytes.
When creating the changelog file be aware of changes which were done in the extractor as well.
Before pushing the changelog to NewPipe's repo, ask other maintainers to review it.
-After pushing the changelog to NewPipe's GitHub repo, updating Weblate is necessary.
+After pushing the changelog to NewPipe's GitHub repo, updating Weblate is necessary.
This enables translators to work on localized versions of the changelog before a release is tagged and published.
Publish on F-Droid
NewPipe is and supports open source software.
@@ -427,29 +353,21 @@ An example commit containing all required changes can be found
-
- Next
-
-
- Previous
-
+