<commit_before># 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.
<commit_msg>[skip] fix spacing on code block<commit_after># 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.

{'fraction_non_alphanumeric': 0.06234516928158547, 'fraction_numerical': 0.030966143682906688, 'mean_word_length': 3.583727530747398, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 2, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '4754564', 'n_tokens_mistral': 1569, 'n_tokens_neox': 1482, 'n_words': 741}