# README Pub Release is a package that automates publishing dart/flutter packages to pub.dev. Pub Release also supports the [simultaneous](/simultaneous-releases) release of multiple related packages. Pub Release performs the following operations: * Run pre/post release 'hook' scripts. * Formats all code using dartfmt * Increments the version no. using semantic versioning after asking what sort of changes have been made. * Creates a dart file containing the version no. in src/version/version.g.dart * Updates the pubspec.yaml with the new version no. * If you are using Git: * Generates a Git Tag using the new version no. * Generates release notes from commit messages since the last tag. * Publish any executables list in pubspec.yaml as assets on github * Allows you to edit the release notes. * Adds the release notes to CHANGELOG.MD along with the new version no. * Publishes the package to pub.dev. ## Sponsored by OnePub Help support Pub Release by supporting [OnePub](https://onepub.dev/drive/24dc5835-29de-4dfc-a9f9-4a3bf112fecb), the private Dart repository. OnePub allows you to privately share Dart packages across your Team and with your customers. Try it for free and publish your first private package in seconds. | ![](/files/Ds8fAIYsVzCDNvU92Diu) |

Publish a private package in five commands:

dart pub global activate onepub

onepub login

cd \

onepub pub private

dart pub publish

| | -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ## Getting Started * Install Pub Release globally with: ```bash dart pub global activate pub_release ``` * Read the [full documentation](https://pubrelease.noojee.dev/) to learn how to use it # Creating a release To update the version no. and publish your project run: ```bash pub_release ``` The pub\_release command will: * prompt you to select the new version number * update pubspec.yaml with the new version no. * create/update a[ version file ](/version-file)in src/util/version.g.dart * format your code with dartfmt * analyze you code with dartanalyzer * Generate a default change log entry using your commit history * Allow you to edit the resulting change log. * push all commits to git * run any scripts found in the [pre\_release\_hook](/hooks) directory. * remove and restore any dependency overrides in your pubspec.yaml * publish your project to pub.dev * run any scripts found in the [post\_release\_hook](/hooks) directory. ### --dry-run You can pass the `--dry-run` flag on the `pub_release` command line. In this case the pub\_release process is run but no modifications are made to to the project (except for code formatting). The `dart pub publish` command is also run with the `--dry-run` switch so suppress publishing the package. ### setVersion You can pass a version no. as an option on the command line. By default Pub Release will prompt the user for a new version no. When you pass the setVersion option the user will not be prompted and the passed version will be used. ### --\[no]-test By default pub-release will run all unit tests (via the critical\_test package) before doing a release. ```bash pub_release --setVersion=2.2.1 ``` If any unit tests fail then the release will be halted. You can by pass the running of unit tests by passing the `--no-test` flag on the command line. ### autoAnswer By default, Pub Release runs in interactive mode and will ask the users a no. of questions during the release process. You can suppress these questions by passing the `--autoAnswer` flag. When you pass the `autoAnswer` flag Pub Release assumes that you answer yes to all questions and takes the default path. ### --\[no]-git ```bash pub_release --autoAnswer ``` By default pub\_release detects if your code is managed by git. ### test If the code is managed by git then it will automatically commit any changes made during the release process as well as creating a release tag. The `--test` flag instructs Pub Release to run all unit tests using the Critical Test package. If any test fails the release will be aborted. You can suppress all git operations by passing the `--no-git` flag. ```bash pub_release --test ``` Note: git operations are only supported against github. If you remote git repo is other than github then you should always use the `--no-git` flag. ### line pub\_release will work if you just have a local git repo with no remote set. The line flag controls the line length of Dart libraries when formatting code. The line length defaults to 80 characters. ### --autoAnswer ```bash pub_release --line=120 ``` If you pass the `--autoAnswer` flag then the user will no be prompted during the release process. ### multi If you use the `--autoAnswer` flag you MUST also pass the `--setVersion` flag. The `multi` flag performs a simultaneous release of multiple related packages. ### --setVersion See [multi-package](/simultaneous-releases) releases for details. The `--setVersion` option allows you to set the version from the command line. If the `--setVersion` option isn't passed then you will be prompted to select the version no. ### --line The `--line` option allows you to override the default line width (80) used when formatting code. We recommend that you use the dart default width of 80. ### --tags By default pub\_release runs every test that is not marked as 'skipped'. You can limit the set of test by passing in the --tag option. ``` pub_release --tag='OnlyTheGoodOnes' ``` See the [test](https://pub.dev/packages/test#tagging-tests) guide for details on how to setup and select tests via tags. ### --exclude-tags By default pub\_release runs every test that is not marked as 'skipped'. You can exclude certain tests by passing in the --exclude-tags option. ``` pub_release --exclude-tags='slow' ``` See the [test](https://pub.dev/packages/test#tagging-tests) guide for details on how to setup and exclude tests via tags. ### --multi Performs a multi-package release. Use the `--multi` flag when you have [multiple related packages](/simultaneous-releases) that need to be released in sync with a single version no. # Multi-package Releases If you have a project that consists of multiple related Dart packages then you may want to perform simultaneous releases of all of the related packages. The Pub Release `multi` command automates simultaneous releases. {% hint style="info" %} For simultaneous releases we recommend using github mono repos to ensure a consistent directory structure as relative paths are used to reference related dependencies. {% endhint %} ## ## ## # Setup To run a simultaneous release you need to provide a `pubrelease.multi.yaml` configuration file that describes each of the packages that need to be released. The `pubrelease.multi.yaml` configuration file will normally be located in the `tool` directory of the main project but can be in any of the package `tool` directories. The `pubrelease.multi.yaml` configuration file simply lists each of the related packages and their relative paths. {% hint style="warning" %} The order of the packages is important. {% endhint %} It is important that you place each package in the correct order for the release process to run successfully. You should place the outermost packages first. For example if you have the following pubspec.yaml files: ``` name: conduit dependencies: conduit_orm: ^1.0.0 conduit_common: ^1.0.0 ``` ``` name: conduit_orm dependencies: conduit_common: ^1.0.0 ``` ``` name: conduit_common ``` In the above examples `conduit_common` is the 'outermost' package and you should therefore order you packages as follows: ```yaml conduit_common: ../common conduit_orm: ../orm conduit: . ``` The above ordering will cause Pub Release to release packages in the following order: * conduit\_common * conduit\_orm * conduit The paths for each package must be relative to the project that contains the `pubrelease.multi.yaml` file. Don't forget to add `pubrelease_multi.yaml` to git. To test you configuration run: ```dart pub_release multi --dry-run ``` # Commands Before you attempt a release you should do a dry run ``` pub_release multi --dry-run or pub_release mulit -d ``` Pub Release will run a dry run on your release to allow you to do basic checks across all of your projects. The dry will will perform each of the following actions: * check that all code is committed * run analyze over your code * format your code * run unit tests for each package You can skip the unit tests by passing: ``` pub_release multi -d -no-test ``` Once you are ready to perform a release run: ``` pub_release multi ``` The `multi` command will still run analyze and format but it will not run the unit tests but it will warn you if a successful unit test run has not been completed for each package. ## Suppress multi release In some edge cases you may want to release just the top level package and not any of the child packages. In this case you can use the --no-multi flag. ```bash pub_release --no-multi ``` This switch is only required if releasing the top level package as child packages can still be released independently. # Circular dependencies If you have projects with circular dependencies then you are in for some pain. A circular dependencies is where A depends on B and B depends on A. With a circular dependency as above, package 'A' must be published before package 'B' but package 'B' must be published before package 'A'. You can get around this problem by creating a temporary package (A or B) that isn't dependent on the other. The correct approach is to move the common code from each package into a third package 'C' that both 'A' and 'B' depend on. # Mono Repo With related packages we recommend that you use a git mono repo. This ensures consistent naming and paths between between the related packages. ### Pubspec.yaml - dependency\_overrides Within your mono repo we recommend that you commit you pubspec.yaml with a dependency\_overrides section listing the relative paths of each of the dependant packages. ``` name: conduit dependencies: conduit_orm: ^1.0.0 conduit_common: ^1.0.0 dependency_overrides: conduit_orm: path: ../orm conduit_common: path: ../common ``` The dependency overrides ensures that when anyone clones your project the code will work correctly out of the box. Of course pub.dev will not let you publish a package with a path based dependency override. Pub Release manages your dependency overrides and will temporarily remove them during the release process so your packages can be published. You can also switch between the two modes using `pub_release override` `pub_release override remove` # Version No.s When doing a simultaneous release Pub Release sets the same no. for every package. Management of version no.s is a little difficult because of the pub.dev policy that once a package is published you cannot unpublish the package. The consequences of this is that, if a simultaneous release fails after it publishes at least one package, then the version no. must again be incremented. As the outermost package is the first to be published we use the version no. from the outermost package to determine the new version no. To avoid too many failed releases we recommend that you us the --dry-run switch to ensure that everything is in order before you do the actual publish. # Hooks Pub Release supports the concept of pre and post release hooks. A hook is simply a script that is run before or after the release is pushed to pub.dev. Hooks live in the following directories: * ``/tool/pre\_release\_hook * ``/tool/post\_release\_hook Where the `project root` is the directory where your pubspec.yaml lives. You can include any number of scripts in each of these directories and they will be run in alphanumerical order. When your hook is called it will be passed the new version as a cli argument: ```bash my_hook.dart 1.0.0 ``` ### dry-run If the `--dry-run` flag is passed to the `pub_release` command then a `--dry-run` flag will be passed on the command line to the hook. If the `--dry-run` flag is passed than your hook should suppress any actions that permanently modify the project. ```bash my_hook.dart --dry-run 1.0.0 ``` # Dependency overrides The Dart pubspec.yaml file allows you to add a dependency\_overrides section to during development. The dependency\_overrides section allows you to specify an alternate location for any package dependency. This often useful during development if you have an associated package that you are also developing. The dependency\_override allows your package to use the associated packages code from your local disk rather than from pub.dev. ``` name: pub_release version: 3.0.0 dependencies: dcli: ^1.0.0 dependency_overrides: dcli: path: ../dcli ``` In the above example the pub\_release project is dependant on dcli. As I'm also the developer of dcli I often make changes to dcli to support pub\_release features. I find it easier to make dcli changes and test them in pub\_release before I publish dcli to pub.dev. The dependency\_override allows me to work on both code bases simultaneous. ## Publishing When it comes time to publish my package I need to remove the dependency\_overrides as pub.dev only allows you to have dependencies on other published packages. pub\_release supports dependency\_overrides by automatically removing them during the release process. Once the package has been published it restores the original overrides. ## Multi-package releases The support of dependency\_overrides is particularly important when doing [multi-package releases](/simultaneous-releases) as it is normally to have overrides for each of the related packages. # Automatic github releases You can use pub\_release to automate the creation of a git 'release' each time you publish your package: Install dcli which we will use to create the hook. ```bash pub global activate dcli dcli install ``` You will need to obtain a github personal access token: Copy the following script to: `/tool/post_release_hook\git_release.dart` ```dart #! /usr/bin/env dcli import 'package:dcli/dcli.dart'; import 'package:settings_yaml/settings_yaml.dart'; void main(List args) { var project = DartProject.current; var pathToSettings = join(project.pathToProjectRoot, 'tool', 'post_release_hook', 'settings.yaml'); var settings = SettingsYaml.load(pathToSettings: pathToSettings); var username = settings['username'] as String; var apiToken = settings['apiToken'] as String; var owner = settings['owner'] as String; var repository = settings['repository'] as String; 'github_release -u $username --apiToken $apiToken --owner $owner --repository $repository' .start(workingDirectory: Script.current.pathToProjectRoot); } ``` on linux and osx mark the script as executable: ```bash sudo chmod +x git_release.dart ``` Create a settings.yaml file in: `/tool/post_release_hook\settings.yaml` {% hint style="danger" %} WARNING: DO NOT ADD SETTINGS.YAML TO YOUR GIT REPO! {% endhint %} Update the settings.yaml file with your git configuration. ``` username: apiToken: owner: repository: ``` Modify each of the strings '' to match your configuration. e.g. ``` username: my@email.com.au apiToken: XXXXXXXX owner: noojee repository: pub_release ``` Now when you run pub\_release it will detect your hook and create a github release. # Attach an asset to a github release You can use pub\_release to automatically attach an asset to a git 'release'. Install dcli which we will use to create the hook. ```bash pub global activate dcli dcli install ``` You will need to obtain a github personal access token: Copy the following script to: `/tool/post_release_hook\publish_asset.dart` ```dart #! /usr/bin/env dcli import 'package:dcli/dcli.dart'; import 'package:settings_yaml/settings_yaml.dart'; void main(List args) { var project = DartProject.current; var pathToSettings = join(project.pathToProjectRoot, 'tool', 'post_release_hook', 'settings.yaml'); var settings = SettingsYaml.load(pathToSettings: pathToSettings); var username = settings['username'] as String; var apiToken = settings['apiToken'] as String; var owner = settings['owner'] as String; var repository = settings['repository'] as String; 'github_release -u $username --apiToken $apiToken --owner $owner --repository $repository' .start(workingDirectory: Script.current.pathToProjectRoot); } ``` ## # Automating releases using Git work flows You can automate the creation of git release tags from a github workflow via: * github\_workflow\_release ``` name: Release executables for Linux on: push: # tags: # - '*' jobs: build: runs-on: ubuntu-latest container: image: google/dart:latest steps: - uses: actions/checkout@v2 - name: setup paths run: export PATH="${PATH}":/usr/lib/dart/bin:"${HOME}/.pub-cache/bin" - name: install pub_release run: pub global activate pub_release - name: Create release env: APITOKEN: ${{ secrets.APITOKEN }} run: github_workflow_release --username --apiToken "$APITOKEN" --owner --repository ``` You need to update the ``, `` and `` with the appropriate github values. You also need to add you personal api token as a secret in github # Version File When creating a release, pub\_release will create or update a dart file containing the package version no. The version file is called: ``` lib/src/version/version.g.dart ``` The contents of the version file will be: ```dart /// GENERATED BY pub_release do not modify. /// pub_release version String packageVersion = '3.0.0'; ``` Where the packageVersion is set to the value in your pubspec.yaml. The packageVersion variable provides a convenient method if you need to display the version no. of your package. # CHANGELOG ## 9.1.0 * revert to using pubspec to get around a problem in pubspec2 * upgraded dcli version ## 9.0.2 * upgraded to dcli 3.x and settings\_yaml 7.x ## 9.0.1 upgraded to settings\_yaml 6.0 ## 9.0.0 * dart 3.x compatability ## 9.0.0-beta.1 * beta version for Dart 3.x compatability ## 8.2.1 * Change the order of the version menu so the option 'keep current' is always the first option. In this way the two most common options are in fixed positions. ## 8.2.0 * upgraded dependencies. ## 8.1.0 * upgraded package dependencies to latest compatible versions. ## 8.0.3 * removed version.g.dart from the barrel file as it was polluting the name space of other dcli apps that use the pub\_release api and have their own dcli version. ## 8.0.1 * Upgraded to dcli 1.33.0 and pubspec2 2.4.1 to fix a bug where we were clearing out the executable script name in the pubspec.yaml. * spelling. ## 8.0.0 * upgraded dependencies and sdk requirements to at least 2.17. * We now check for a pubrelease.multi.yaml and if it exists we expect the user to pass the multi command or the --no-multi switch. * Added --no-multi flag to suppress doing a multi build. * upgraded to the latest pubspec package to fix a problem with platforms being written out with a null value. ## 7.3.3 * Upgraded to pubspec 2.3.0 to fix a problem with platforms. The pubspec code was incorrectly adding a 'null' after the platform name so 'linx:' became 'linux: null' ## 7.3.0 Fixed a bug in the dependency version updates for the multi command. It was scaning from the wrong root dir for deps. We now use the multi settings file to guide the update process. ## 7.2.2 * added support for updating the dependency version no. when doing a multi release ## 7.2.0 * ENH: added support for pre-release versioning. ## 7.1.19 * spelling. ## 7.1.18 * Applied lint\_hard * Added documentation key to pubspec.yaml. lint cleanups. * corrected github\_release to use the same settings file settings.yaml. ## 7.1.17 * fixed some deprecation warnings. * Fixed a bug on first run if a changelog.md file didn't already exists. We now created it. ## 7.1.8 upgraded to dcli 1.5.3 changed hooks to explicity run dart for .dart hooks until we resolve dcli problems with the dart file association under windows. ## 7.1.7 upgraded to dcli 1.5.2 remove the units tests dependency on having dcli installed. Moved to new version of settings.yaml to fix bugs with empty content. ## 7.1.6 Missed on of the invalid array refernces. ## 7.1.5 Added overrides back in. upgraded to dcli 1.5.2 Fixed a bug in the git procelain parsing. ## 7.1.4 Added logic to ignore pre and post hooks which are not compatible with the current platform. e.g. .sh scripts on windows ## 7.1.3 update the dcli version no. as we had left it too wide. We now run critical test with verbose logging if pub\_release was called with the verbose flag. ## 7.1.2 Exported the multisettings class as part of the public api so the list of depdencis can be shared by others. ## 7.1.1 * change DartScript.current to self as current is now deprecated. * Added logic to suppress the running of critical\_test if no test directory exits. * Fixed a bug where we crash if the .gitignore file doesn't exist. * modified to use dart pub as pub is going away. * Add getting started to readme and link to docs ## 7.1.0 New Features: * Added option to suppress git operations --no-git Fixes: * Added logic to suppress `dart format` if a directory is non existant or empty. ## 7.0.0 First working version of multi. Now supports running unit tests as part of the release process via critical\_test. Changed exit codes from -1 to 1 as this seems more standard. ## 6.4.0 Added --dry-run flag. ## 6.3.0 upgraded to dcli 1.0 ## 6.2.0 Change the change log editing so that the user gets to see the enitre change log. This is particullarly useful if a release fails an you want to re-edit the release notes. Currently we just append the release notes a second time which is not desirable. ## 6.1.0 Released 6.1.0 improvement to log messags. Fixed incorrect line argument to dart format. Added missing logic for line length. ## 6.1.0 improvement to log messags. Fixed incorrect line argument to dart format. Added missing logic for line length. ## 6.1.0 Added list of extensions to ignore if found in the hook directory. Now allows any type of executable to be used as a hook. Prints an error if invalid command line arguments are passed. Added missig implementation for controlling the formatters line length. ## 6.0.2 upgraded final libraries to nndb versions. upgraded to latest version of dcli ## 6.0.1 Upgraded to latest dcli. ## 6.0.0 Upgraded to nnbd. ## 5.0.7 fixed string formatting problem in formatCode Added logic to commit formatted fils. formatting. We commit any files changed by dartfmt. ## 5.0.4 Cleaned up name/version on startup ## 5.0.3 pub\_relesae was printing the wrong app name on start up. ## 5.0.2 Fixed release names. ## 5.0.1 fixed latest release name. ## 5.0.1 Changed the 'latest' naming convention from 'latest-' to 'latest.' as git hub saw the '-' as meaning the tag was a pre-release. Now prints version no. when starting. ## 5.0.0 Changed code to force the user to commit before doing a release. This allows us to automatically push the committed version changes. Without this the assets attached to git hub have the old version no. Staged the files we modified so we can commit them. quoted the message so it survies arg parsing. ## 4.3.1 Fixed a bug in the deleteTag method as it was using the wrong path to the tags. renamed getByTagname to getReleaseByTagname This bug was causing the 'latest' tag to not be updated. removed sperious } in string. released 4.3.0 formatting ## 4.3.0 We can once again upload assets as part of a release. Fixed a bug where the mimetype was set to null. The result was a crash in the http\_impl class. Additional verbose messages. Fixed a bug under windows where we appended .exe.exe to the mimeType. ## 4.2.0 Reverted back to dart 2.8.4 to over come ## 4.1.0 Added back in logic to release assets as it now seems to be working? upgraded to latests dcli which has a changed method signature. Now pulling credentials from settings.yaml upgraded to latest dcli version. restored test code to working state. renamed to simple\_github.dart ## 4.0.4 moved from using pub to dart pub. ## 4.0.3 Added hook to active lastest version of pub release locally after we do a release. removed message re attaching assets as we are not currently doing that. ## 4.0.2 Removed ability to add executablles as assets to git release until issue is fixed. ## 4.0.1 Updated dcli version to 0.40.0 ## 4.0.0 Removed getPubSpec. You should use findPubspec followed by Pubspec.fromFile ## 3.0.0 removed the --suffix option as we were mis-using it. We had been using the suffix to indicate os version but github sees it as a 'pre-release' indicator. Going forward the assests should all be attached to a single release and the asset names should indicate the platform. Fixed bugs around the recreation of the 'latests' tag Fixed bug where we were not closing the http connection. ## 2.1.20 implemented the lint package. Fixed a bug which caused no hooks to be returned. ## 2.1.19 Fixed hook messages. Fixed bugs in the git detection and push of tags. exposed Git as part of the public api. ## 2.1.18 Fixed a bug where pub\_release only search the dart package root for .git. The dart package could be part of a larger project in which case we need to search up the tree for .git. ## 2.1.17 tweaks to the release process. ## 2.1.16 Added new addAsset method to make it easy to publish an asset. ## 2.1.15 added note about hook scripts. upgraded package versions and added example.md. ## 2.1.14 pub updated. improved the doco on automating git releases. ## 2.1.13 reduced min dart sdk to 2.7 so would work on a pi. ## 2.1.12 upgraded to dcli 0.34.0 ## 2.1.11 corrected the filename for settings. ## 2.1.10 ignored settings.yaml and add tool directory. moved credentials into settings.yaml. ## 2.1.9 upgraded to dcli 0.33.6 ## 2.1.8 upgraded to dcli 0.32.0 ## 2.1.7 upgraded to dcli 0.30.0 ## 2.1.6 Upgraded to dcli 0.29.2 ## 2.1.5 upgraded to dcli 0.28.0 ## 2.1.4 FIX: a bug was causing the code to fail to update the latest release. We are now explicitly deleting the tag and then recreating it. ## 2.1.3 Final test of release hooks. No code changes. ## 2.1.2 changed hooks to hook to conform to dart policy of singular form for directory names. Made the suffix optional. Improved the readme to include instructions on creating release tags in github. ## 2.1.1 Used 2.1.0 to create a release so that it generates the github release tag an assets. ## 2.1.0 pub\_relase can no create a release in github and add each exectable listed in the pubspec.yaml as an asset attached to the release. update workflow notes. Added back in the assest/release tag as github.dart is almost ready. Upgraded to dcli 0.27 ## 2.0.2 exported pub\_semver so users have access to the Version class. ## 2.0.1 Small fix as it was displaying the old version no.rather than the new one. ## 2.0.0 Cleaned up the Version api. Added pedeantic. ## 1.1.4 upgraded to dcli 0.24 ## 1.1.3 added the dart static analyzer to the set of tasks performed. cleaned up the github\_release and workflow apps. Renamed them and added additional doc and examples of their usage. color coded hook messages. The git\_release exec has been disabled until we get the new version of github.dart. ## 1.1.2 color coded hook messages. upgraded to dcli. ## 1.1.1 Fixed a bug where the pre-release hook path was buggered up. Fixed a message. ignored credentials. Fix git\_release and create\_tag so they will work from the root dir of any project. Widened the dcli version constraints as required by pub.dev ## 1.1.0 Added support for pre/post release hooks. stand alone cli app to create a git hub tag. Added settings\_yaml dependancy as no longer part of dcli. ## 1.0.13 upgraded to dcli. Added new exe git\_release which creates a git release tag and attaches each executable as an asset. ## 1.0.12 made git\_hub a dev dependency. ## 1.0.11 Upgraded to dshell 1.11.0 and fixed breaking changes. ## 1.0.10 Added missing space in message. ## 1.0.9 upgraded packages. Fixed bug where when selecting a custom version no. we would ask for the version twice. ## 1.0.8 no longer asking a user to create the git tag. ## 1.0.7 moved the option to keep the current version down the list as it is rarely used. released 1.0.6 ## 1.0.6 Was displaying the old version when asking the usr to confirm the version. ignored bash history. Added option to set the version and ask no questions. ## 1.0.5 ## 1.0.5 ## 1.0.5 ## 1.0.5 ## 1.0.5 Add option to set the version no. from the cli ## 1.0.4 removed the version message as it was just confusing when you are looking to update the actual packages version. Added a git pull at the start of the process. ## 1.0.3 Added version to start. Had the exists logic backwards when creating a CHANGLOG.md ## 1.0.2 we now create the CHANGELOG.md file if it doesn't exist. ## 1.0.1 Fixed a bug when detecting git. Change message to only recommend commiting as we will do the push. ## 1.0.0 Fixed a bug where it failed to detect that git was being used. Fixed a bug where it throws an error if a tag doesn't already exist. ## 0.1.4 released 0.1.4 Release of version 0.1.3 Update .gitignore Merge pull request #1 from bsutton/add-license-1 Create LICENSE initial commit ## 0.1.4 Fixed the change log :) Added new option to keep the current version. ## 0.1.2 Added a new option to keep the current version. ## 0.1.1 Added a missing 'executeables' statement from pubspec.yaml ## 0.1.0 First release of pub\_release ## 0.1.0 First release of pub\_release ### 0.1.1 ### 0.1.0 My first release ### 0.1.0 My first release. ### 1.0.0 * Initial version, created by Stagehand # example ```bash cd pub_release ``` See the README.md for details on adding pre/post processing hooks.