v0.6.1

• Upgraded the dependency on zip to 2.4.1. Previously, ubi pinned zip 2.2.3, which was yanked, because the 2.3.0 release broke ubi's tests.

v0.6.0

• The UbiBuilder::github_token and UbiBuilder::gitlab_token methods are deprecated in favor of a new ``UbiBuilder::token` method. These deprecated methods will be removed in a future release.
• Added support for release artifacts with a .jar extension. Based on PR #110 from @vemoo.
• ubi could incorrectly pick a release for Android when running on Linux aarch64 platforms. Reported by @jahands (Jacob Hands). GH #111.

v0.5.2 - Fix regression in v0.5.0

0.5.2 - 2025-02-22

• This is identical to 0.5.1, but it was necessary to work around a bug in my GitHub release
  automation. The 0.5.1 is no longer available on GitHub, but the crates.io releases still exist and
  there's no issue with using them.

0.5.1 - 2025-02-22

• Fixed a bug introduced in the last release where ubi could pick a file with a partial match over
  an exact match, but only with zip files. Reported by @oalders (Olaf Alders). GH #100.

v0.5.0

• On Windows, ubi now looks for files with .bat extensions as an executable. This applies both to releases of standalone files and executables in an archive file (tarball or zip). Based on work by @timothysparg (Tim Sparg) in PR #97.
• If there are no files that are an exact match for the project name in an archive file, ubi will now look for files that start with the project name. On non-Windows, boxes, this will only match executables. On Windows, this will only match .bat or .exe files. Based on work by @timothysparg (Tim Sparg) in PR #97.

v0.4.2

• Added all to the list of architecture strings to match against for macOS on ARM64. It looks like this is in use in the wild. See https://github.com/segmentio/golines/releases/tag/v0.12.2 for an example. Reported by Shyam Subramaniyam.

v0.4.1

• Fixed a bug where ubi where zip files containing a directory that matched the expected executable name caused ubi to extract the directory instead of the actual executable, resulting in a 0-length file. Based on a PR #89 from @fiadliel (Gary Coady). Fixes #88.
• Added a new UbiBuilder::rename_exe_to method, along with a --rename-exe-to CLI flag. When this is set, the installed executable will use the name given here, instead of the name that it has in the downloaded file. This is useful for projects that do releases where the executable name includes things like a version number of platform information. Based on discussion in #86.
• Added support for release artifacts with a .pyz extension. These are zip files containing Python code, and they can be directly executed. Based on PR #85 from @itochan (Kazunori Jo).
• Added support for release artifacts with a .AppImage extension. These will only be picked when running Linux. Requested by @SaulH (Saul Reynolds-Haertle). GH #86.
• Fixed a bug where ubi would consider an asset with .exe extension on non-Windows platforms. In practice, this would probably only have been an issue for projects with exactly one release artifact, where that artifact had a .exe extension.
• The --extract-all CLI option added in the previous release did not have any description in the help output. This has been fixed.

v0.4.0

• The ubi CLI tool now takes an optional --extract-all argument. If this is passed, it will only look for archive files and it will extract the entire contents of an archive it finds. There is also a new corresponding UbiBuilder::extract_all method. Requested by @Entze (Lukas Grassauer). GH #68.
• The UbiBuilder::install_dir method now takes AsRef<Path> instead of PathBuf, which should make it more convenient to use.
• Previously, ubi would create the install directory very early in its process, well before it had something to install. This meant that if it failed to find an asset, couldn't download the asset, or other errors happened, it would leave this directory behind. Now it creates this directory immediately before writing the executable it found to disk.

v0.3.0

• ubi now works with GitLab in addition to GitHub. For the command-line program, if the value you pass to --project has a gitlab.com domain, like https://gitlab.com/gitlab-org/cli, this will just work. If you just pass a project name, like gitlab-org/cli, then you will also need to pass --forge gitlab in order to tell ubi to use gitlab. The library interface works the same way, with a new UbiBuilder::forge method. Requested by @SangeloDev. GH #51.
• When looking for macOS assets, ubi will now match against macosx in asset names, not just macos and osx. Implemented by @kattouf (Vasiliy Kattouf). GH #80.
• Added a new --api-url-base CLI argument. This should allow you to use ubi with Enterprise installations of GitHub and GitLab. Requested by @oalders (Olaf Alders). GH #69.
• Renamed the UbiBuilder::url_base method to api_base_url and changed it to take a &str instead of a String, which is consistent with all the other builder methods.

v0.2.4

• ubi will now look for just "mac" or "Mac" in a filename when running on macOS. Previously, ubi would not treat a filename like "foo-mac-x86-64.tar.gz" as a match for macOS. Reported by @jdx (Jeff Dickey). GH #79.

v0.2.3

• Fixed the code to detect whether the filename includes a version number that looks like an extension. If the filename ended with the version, like foo-1.2.3, then this was not handled properly. It only worked if there something after the version as well, like foo-1.2.3-linux-amd64. Based on a bug report by @FelisNivalis. GH #77.