ReVanced-Mirror/Apktool
1
0
Fork 0
mirror of https://github.com/revanced/Apktool.git synced 2024-12-05 02:22:55 +01:00
Code Issues Projects Releases Wiki Activity

Update INTERNAL doc for instructions how to publish a release

Browse Source
This commit is contained in:
Connor Tumbleson 2017-01-23 08:19:14 -05:00
parent d386bf447d
commit 60b5b8e4b1
No known key found for this signature in database
GPG Key ID: C3CC0A201EC7DA75
1 changed files with 178 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

178
INTERNAL.md
View File

@ -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. # Building aapt binaries.
The steps taken for building our modified aapt binaries for apktool. The steps taken for building our modified aapt binaries for apktool.