diff --git a/INTERNAL.md b/INTERNAL.md index 20f46646..da16d735 100644 --- a/INTERNAL.md +++ b/INTERNAL.md @@ -1,3 +1,181 @@ +# Releasing a new version. + +The steps taken for slicing an official release of Apktool. + +### Taging the release. + +Inside `build.gradle` there are two lines. + + apktoolversion_major + apktoolversion_minor + +The major variable should be left unchanged. If done correctly, it will already be the version +you are about to release. In this case `2.2.2`. The minor variable should read `SNAPSHOT` as +the `2.2.2` release up until this point was `SNAPSHOT` releases (Unofficial). + +We need to remove the `SNAPSHOT` portion and leave the minor version blank. An example can be +found [here](https://github.com/iBotPeaches/Apktool/commit/96b70d0be7513c5a1e5d3a3b9a75e4e2b076ad79). + +After we remove `SNAPSHOT` we need to make the version commit. Organization and following patterns +is crucial here. This commit should have 1 change only - the change above. Now commit this change +with the commit message - `version bump (x.x.x)`. + +At this point we now have the commit of the release, but we need to tag it using the following message. + + git tag -a vx.x.x -m "changed version to vx.x.x" + +For example for the `2.2.1` release. + + git tag -a v2.2.1 -m "changed version to v2.2.1" + +### Building the binary. + +In order to maintain a clean slate. Run `gradlew clean` to start from a clean slate. Now lets build +the new version. We should not have any new commits since the tagged commit. + + ./gradlew build fatJar proguard release + +The build should tell you what version you are building and it should match the commits you made previously. + + ➜ Apktool git:(master) ./gradlew build fatJar proguard release + Building RELEASE (master): 2.2.2 + +### Testing the binary. + +Now the release binary is built in the same location as all other builds. Run this version against +some of the fixed bugs in this release. This is a simple test to ensure the build had no errors. + +Copy the jar to any location to prep for uploading. The pattern we name the jars is + + apktool_x.x.x.jar + +Or in the case of the last release - `apktool_2.2.1.jar` + +Once you have the jar in this form. Record the md5 hash of it. This can be done using `md5sum`. + +This can be shown for the `2.2.2` release like so + + ➜ Desktop md5sum apktool_2.2.2.jar + 1e6be08d3f9bb4b442bb85cf4e21f1c1 apktool_2.2.2.jar + +Remember this hash. This is the local hash. This is our master hash. All others (Bitbucket, Backup) +must match this. + +### Lets get uploading. + +Lets make sure we actually pushed these release changes to the repo (Both Github & Bitbucket) + + git push origin master + git push origin vx.x.x + + git push bitbucket master + git push bitbucket vx.x.x + +We upload the binaries into 3 places. + +1. [Bitbucket Downloads](https://bitbucket.org/iBotPeaches/apktool/downloads) +2. [Github Releases](https://github.com/iBotPeaches/Apktool/releases) - Since `2.2.1`. +3. [Backup Mirror](http://connortumbleson.com/apktool/) + +#### Bitbucket + +This one is pretty easy. Head to the URL attached to the hyperlink #1 above. There will be a "Add Files" +button on the top right of the page. Upload the `apktool_x.x.x.jar` file. + +After it is uploaded. Immediately visit the page and download it. Check the `md5` for a match. + +#### GitHub + +This option will not work until the tag is pushed. You can head to this [page](https://github.com/iBotPeaches/Apktool/releases/new) +to draft a new release. The `Tag version` dropdown will have the new tag. In this case `v2.2.2`. + +Select that option and make the title `Apktool vx.x.x`. There will be a description field on this release. +Hold tight, we link the release blog post in this field, but we can edit the release after the fact to add this. + +Upload the binary `apktool_x.x.x.jar` and submit the release. + +#### Backup Server + +Access to this server is probably limited so this option may not be possible. SSH into the +`connortumbleson.com` server with username `connor`. Head to `public_html/apktool` and upload +the `apktool_x.x.x.jar` to it. + +Now re-generate the md5 hashes for these files. + + md5sum *.jar > md5.md5sum + +Check the `md5.md5sum` file for the hashes. The file will look something like this. + + 6de3e097943c553da5db2e604bced332 apktool_1.4.10.jar + ... + 1e6be08d3f9bb4b442bb85cf4e21f1c1 apktool_2.2.2.jar + +The hashes match so we have uploaded the binaries to all 3 locations. Time to get writing the release +post. + +We currently blog the releases on the [Connor Tumbleson personal blog](https://connortumbleson.com/). +This may change and the formatting of these release posts change over time. + +Some recent releases for understanding the pattern can be found below. + +1. [2.2.1](https://connortumbleson.com/2016/10/18/apktool-v2-2-1-released/) +2. [2.2.0](https://connortumbleson.com/2016/08/07/apktool-v2-2-0-released/) +3. [2.0.2](https://connortumbleson.com/2015/10/12/apktool-v2-0-2-released/) +4. [2.0.0](https://connortumbleson.com/2015/04/20/apktool-v2-0-0-released/) + +So write the post. I tend to always include the following: + +1. Image of release for featured image when reshared on socials. +2. Quick sentence or two for SEO to describe the meat of this release. +3. Commit count and total for this release with author names. +4. Changelog linking to the bugs that were fixed. +5. Download including the md5 hash. +6. Link dump to Project Site, GitHub, Bug Tracker and XDA Thread. + +Now that you've written this post. We need to go post it in places and update places where +Apktool is released. + +### XDA Thread + +We have a [thread](https://forum.xda-developers.com/showthread.php?t=1755243) on XDA Developers. +This thread follows the same pattern for all releases. + +When writing a response to the XDA thread we follow another pattern of release notes. These examples +can be found below: + +1. [2.2.2](https://forum.xda-developers.com/showpost.php?p=70687935&postcount=4635) +2. [2.2.1](http://forum.xda-developers.com/showpost.php?p=69188139&postcount=4478) +3. [2.0.0](http://forum.xda-developers.com/showpost.php?p=60255972&postcount=3063) + +### Apktool Website + +The Apktool project website has a few locations to update: + +1. The homepage intro +2. The download link in header +3. The changelog page +4. The footer of homepage with history of releases. + +The easiest way to describe this is to just link to a [previous release](https://github.com/iBotPeaches/Apktool/commit/5ef77bf01cf3625cb1dd1981234b3854b02496e2). + +### Update Milestones + +Now that we've released a version, we should hopefully have no more tickets in the release just published. +If there are, move those tickets to the next milestone. + +You can head to [milestones](https://github.com/iBotPeaches/Apktool/milestones) to close the just +released version and create another. + +I tend to create the next release (In this case `2.2.3`) with an ETA of 3 months in the future. This +is just a guideline but helps me to release a new version every 3 months. + +### Social Spam + +The final step is to send this release into the wild via some social posting. Head to the blog +where the release post was and send that link to Twiter, Google and whatever else you use. + +Relax and watch the bug tracker. + # Building aapt binaries. The steps taken for building our modified aapt binaries for apktool.