chore: revert version to match actual version

README.md

@@ -1,64 +1,78 @@
 # Release Tools
 
-A collection of scripts to help with creating releases for publishing libraries and dart packages.
+A collection of scripts to help with creating releases for publishing libraries
+and dart packages.
 
+[![build](https://github.com/asartalo/release_tools/actions/workflows/ci.yml/badge.svg)](https://github.com/asartalo/release_tools/actions/workflows/ci.yml)
+[![Coverage Status](https://coveralls.io/repos/github/asartalo/release_tools/badge.svg?branch=main)](https://coveralls.io/github/asartalo/release_tools?branch=main)
+[![Pub](https://img.shields.io/pub/v/release_tools.svg)](https://pub.dev/packages/release_tools)
 
-[![build](https://github.com/asartalo/release_tools/actions/workflows/ci.yml/badge.svg)](https://github.com/asartalo/release_tools/actions/workflows/ci.yml) [![Coverage Status](https://coveralls.io/repos/github/asartalo/release_tools/badge.svg?branch=main)](https://coveralls.io/github/asartalo/release_tools?branch=main)
- [![Pub](https://img.shields.io/pub/v/release_tools.svg)](https://pub.dev/packages/release_tools)
 ## Features
 
 - `release_tools update_version` - Update the version number of pubspec.yaml
 - `release_tools next_version` - Get the next version based on commits.
-- `release_tools should_release` - Check if we can create a release based on commits that follow the [Conventional Commit](https://www.conventionalcommits.org/) spec.
-- `release_tools changelog` - Update changelog based on commits that follow the Conventional Commit spec.
+- `release_tools should_release` - Check if we can create a release based on
+  commits that follow the
+  [Conventional Commit](https://www.conventionalcommits.org/) spec.
+- `release_tools changelog` - Update changelog based on commits that follow the
+  Conventional Commit spec.
 - `release_tools update_year` - For syncing years on license files.
 - `release_tools remote_tag_id` - Get the commit id of a remote tag.
 - `release_tools current_version` - Get the current version of this package.
-- `release_tools prepare_release` - Complete release prep logic using the tools previously mentioned.
+- `release_tools prepare_release` - Complete release prep logic using the tools
+  previously mentioned.
 
 ## Notes Before Using
 
 To be effective, `release_tools` makes a few assumptions about a project:
 
 - It uses `git` as scm
-- Commits follow the [Conventional Commit](https://www.conventionalcommits.org/) spec
+- Commits follow the [Conventional Commit](https://www.conventionalcommits.org/)
+  spec
 - Versions are tagged
 
-If your project needs are typical, you probably only need `prepare_release`. However, if you need more fine-grained control, use the other scripts as you see fit.
+If your project needs are typical, you probably only need `prepare_release`.
+However, if you need more fine-grained control, use the other scripts as you see
+fit.
 
 ## Installation
 
-I recommend installing `release_tools` globally so that it won't interfere with your project's own dependecies. Constrain it to a specific version to limit supply-chain exploits.
+I recommend installing `release_tools` globally so that it won't interfere with
+your project's own dependecies. Constrain it to a specific version to limit
+supply-chain exploits.
 
 ```sh
-$ pub global activate release_tools 0.3.2
+$ pub global activate release_tools 0.3.1
 ```
 
 ## Scripts
 
 ### update_version
 
-The following command will update the version on `pubspec.yaml` on the current directory to version 1.0.1
+The following command will update the version on `pubspec.yaml` on the current
+directory to version 1.0.1
 
 ```sh
 $ release_tools update_version 1.0.1
 ```
 
-If you want to update the version on a text file other than `pubspec.yaml`, use the `--file` option:
+If you want to update the version on a text file other than `pubspec.yaml`, use
+the `--file` option:
 
 ```sh
 $ release_tools update_version --file="README.md" 1.0.1
 ```
 
-By default, it will look for strings that look like semver-flavored version strings. If you want to be specific, you can specify a template for replacement. For example, if the `README.md` file contains the following text:
+By default, it will look for strings that look like semver-flavored version
+strings. If you want to be specific, you can specify a template for replacement.
+For example, if the `README.md` file contains the following text:
 
 ```markdown
 # My Project
 
 Current Version: 1.0.0
 
 Starting from version 1.0.0, all alert buttons will be red.
-
 ```
 
 Running the following command...
@@ -75,7 +89,6 @@ $ release_tools update_version --file="README.md" --template="Current Version: [
 Current Version: 1.0.1
 
 Starting from version 1.0.0, all alert buttons will be red.
-
 ```
 
 ### next_version
@@ -85,7 +98,9 @@ $ release_tools next_version 1.0.1
 $ release_tools next_version
 ```
 
-If you don't pass the version to increment from, it will attempt to get the version from `pubspec.yaml`. The script will return the next version based on the releasable commit logs that follow the conventional commit spec.
+If you don't pass the version to increment from, it will attempt to get the
+version from `pubspec.yaml`. The script will return the next version based on
+the releasable commit logs that follow the conventional commit spec.
 
 For example, if the commit logs contain a commit with the following message:
 
@@ -96,19 +111,22 @@ BREAKING-CHANGE: this changes everything
 ```
 
 ... then it will output a new major version:
+
 ```
 2.0.0
 ```
 
-By default, `next_version` considers all the logs from the beginning of the commit history but you can also specify a starting range:
+By default, `next_version` considers all the logs from the beginning of the
+commit history but you can also specify a starting range:
 
 ```sh
 $ release_tools next_version --from=abcde1234 1.0.1
 ```
 
 ...where `--from` should point to a commit id.
 
-It will also increment the build number if the version on the `pubspec.yaml` or the version passed has it if there are releasable commits.
+It will also increment the build number if the version on the `pubspec.yaml` or
+the version passed has it if there are releasable commits.
 
 ```sh
 $ release_tools next_version 1.0.1+1
@@ -131,7 +149,8 @@ $ release_tools next_version --noBuild 1.0.1+1
 
 ### should_release
 
-The following will print 'yes' to stdout if there are releasable commits, or 'no' if there are none.
+The following will print 'yes' to stdout if there are releasable commits, or
+'no' if there are none.
 
 ```sh
 $ release_tools should_release
@@ -140,7 +159,9 @@ $ release_tools should_release --from=abcde1234
 no
 ```
 
-"Releasable" here means that the commit logs contain at least one `fix` (PATCH), `feat` (MINOR), or `BREAKING` (MAJOR) logs as described in the conventional commits spec.
+"Releasable" here means that the commit logs contain at least one `fix` (PATCH),
+`feat` (MINOR), or `BREAKING` (MAJOR) logs as described in the conventional
+commits spec.
 
 ### changelog
 
@@ -174,7 +195,9 @@ A sample changelog would be the following:
 
 ### update_year
 
-A simple tool for updating the year on LICENSE files. Note that the logic is really simple. It simply updates the first 4-digit number to the current year which may or may not be enough for your needs.
+A simple tool for updating the year on LICENSE files. Note that the logic is
+really simple. It simply updates the first 4-digit number to the current year
+which may or may not be enough for your needs.
 
 ```sh
 $ release_tools update_year
@@ -216,7 +239,9 @@ $ release_tools current_version
 Complete release preparation logic with the following steps:
 
 1. Get the current version
-2. Get the commits from the last version tag or, if a version tag is not available for the last release, it will get them from the beginning of the commit history
+2. Get the commits from the last version tag or, if a version tag is not
+   available for the last release, it will get them from the beginning of the
+   commit history
 3. Check if a release is appropriate and if so...
 4. Update version on pubspec including incrementing the build number
 5. Create summary changelog from the commits
@@ -249,16 +274,20 @@ SUMMARY:
 - prepare_release command ([877d63e](commit/877d63e))
 ```
 
-
-If you need a summary of the result of the script run, you can pass `-w` to write some summary files like in the following:
+If you need a summary of the result of the script run, you can pass `-w` to
+write some summary files like in the following:
 
 ```sh
 $ release_tools prepare_release -w
 ```
 
-This will create two files, `VERSION.txt` and `RELEASE_SUMMARY.txt` which will contain just the version for release and the summary of changes, respectively.
+This will create two files, `VERSION.txt` and `RELEASE_SUMMARY.txt` which will
+contain just the version for release and the summary of changes, respectively.
 
 ## Similar Tools
 
-- [pub_release](https://pub.dev/packages/pub_release) - A much more mature release tool. I wanted to use this tool on my projects but found I didn't need a lot of its features. Still awesome!
-- [melos](https://pub.dev/packages/melos) - This one is geared towards monorepos.
+- [pub_release](https://pub.dev/packages/pub_release) - A much more mature
+  release tool. I wanted to use this tool on my projects but found I didn't need
+  a lot of its features. Still awesome!
+- [melos](https://pub.dev/packages/melos) - This one is geared towards
+  monorepos.

lib/release_tools_version.dart

@@ -1 +1 @@
-const releaseToolsVersion = '0.3.2';
+const releaseToolsVersion = '0.3.1';

pubspec.yaml

@@ -1,6 +1,6 @@
 name: release_tools
 description: A collection of scripts to help with creating releases and publishing libraries.
-version: 0.3.2
+version: 0.3.1
 homepage: https://github.com/asartalo/release_tools
 
 environment: