What’s Changed

• Exit with 1 if anything failed (#114) @basnijholt
• Skip coverage (#112) @marcellaholm

What’s Changed

• BUG: Fix extension on Windows in README generation (#111) @basnijholt
• Fix eza alias in example config (#109) @basnijholt
• ⬆️ Update astral-sh/setup-uv action to v6 (#106) @renovate[bot]

What’s Changed

• Prefer i686 over even more ancient i386 (i.e., create linux/i686/bin/tool instead of linux/386/bin/tool) (#108) @basnijholt
• Rely on Keychain being released in examples (#107) @basnijholt

Previous release notes:

dotbins v2.0.0 Release Notes 🎉

This is a major release for dotbins, introducing significant improvements to version tracking, reproducibility, and internal consistency. The core changes revolve around a more robust manifest system and the ability to pin tool installations precisely to your manifest file.

💥 Breaking Changes

1. versions.json Renamed to manifest.json:

   • The file used to track installed tool versions, previously named versions.json, has been renamed to manifest.json. This name better reflects its purpose and aligns with common terminology.
   • Migration: dotbins v2.0.0 will automatically detect an existing versions.json on the first run and convert it to the new manifest.json format, deleting the old file.
   • Impact: If you were manually interacting with versions.json or tracking it in Git, you will need to update your workflows to use manifest.json. Please commit the new manifest.json after the first run. Due to the automatic conversion and internal changes, the first sync after upgrading might result in some tools being re-downloaded.

2. Internal Version Tracking Changed to Store Full "Tag":

   • Previously, the manifest stored a normalized version string, often removing the leading v (e.g., 1.2.3). It now stores the exact Git tag as it appears on GitHub (e.g., v1.2.3 or 1.2.3) under the key tag.
   • Reason: This change is essential for ensuring dotbins can reliably re-download the exact same release specified by the tag. GitHub release tags are not always consistent (some use a v prefix, others don't). Storing the precise tag allows dotbins to request the correct release from the GitHub API, which is crucial for features like sync --pin-to-manifest and when using the tag parameter in your dotbins.yaml.
   • Impact: While display commands like dotbins status will often still show a normalized version number for readability, the underlying data in manifest.json has changed. If you were parsing the manifest file directly, you'll need to adjust to use the tag key and expect the full tag string (potentially including the v).

✨ New Features

1. Pinning to Manifest with dotbins sync --pin-to-manifest:
   • A new --pin-to-manifest flag has been added to the sync command.
   • When used, dotbins sync will ignore the latest release information from GitHub and any tag specified in your dotbins.yaml. Instead, it will install the exact tag recorded for each tool in your manifest.json file.
   • Use Case: This is incredibly useful for ensuring reproducibility across environments or CI/CD pipelines. By committing your manifest.json to version control, you can guarantee that dotbins sync --pin-to-manifest always installs the same tool versions everywhere, regardless of newer releases on GitHub.
   • Example:

     # Ensure installed tools match the versions in manifest.json exactly
     dotbins sync --pin-to-manifest

⬆️ Migration

1. Run any dotbins command (e.g., dotbins sync, dotbins status) with v2.0.0 installed.
2. The tool will automatically detect versions.json, log a warning about the conversion, create manifest.json with the updated format, and delete versions.json.
3. If you track your ~/.dotbins directory (or your custom tools_dir) in Git, commit the new manifest.json file.
4. Review the output of your first dotbins sync run after upgrading, as some tools might be re-downloaded due to the manifest format changes.

PR list

• fix(nushell): Correct integration script generation for compatibility (#104) @basnijholt
• Add --pin-to-manifest (#103) @basnijholt
• Store URL in manifest.json (#101) @basnijholt
• Feat: Store exact tags in Manifest for reproducibility and support {tag} pattern (#98) @basnijholt

I believe these changes make dotbins a more robust and predictable tool for managing your CLI binaries within your dotfiles workflow. Thank you for using dotbins! Please report any issues or provide feedback on the GitHub repository.

v2.1.0

What’s Changed

• Allow dotbins sync --current even for unconfigured systems (#105) @basnijholt

Previous release notes:

dotbins v2.0.0 Release Notes 🎉

This is a major release for dotbins, introducing significant improvements to version tracking, reproducibility, and internal consistency. The core changes revolve around a more robust manifest system and the ability to pin tool installations precisely to your manifest file.

💥 Breaking Changes

1. versions.json Renamed to manifest.json:

   • The file used to track installed tool versions, previously named versions.json, has been renamed to manifest.json. This name better reflects its purpose and aligns with common terminology.
   • Migration: dotbins v2.0.0 will automatically detect an existing versions.json on the first run and convert it to the new manifest.json format, deleting the old file.
   • Impact: If you were manually interacting with versions.json or tracking it in Git, you will need to update your workflows to use manifest.json. Please commit the new manifest.json after the first run. Due to the automatic conversion and internal changes, the first sync after upgrading might result in some tools being re-downloaded.

2. Internal Version Tracking Changed to Store Full "Tag":

   • Previously, the manifest stored a normalized version string, often removing the leading v (e.g., 1.2.3). It now stores the exact Git tag as it appears on GitHub (e.g., v1.2.3 or 1.2.3) under the key tag.
   • Reason: This change is essential for ensuring dotbins can reliably re-download the exact same release specified by the tag. GitHub release tags are not always consistent (some use a v prefix, others don't). Storing the precise tag allows dotbins to request the correct release from the GitHub API, which is crucial for features like sync --pin-to-manifest and when using the tag parameter in your dotbins.yaml.
   • Impact: While display commands like dotbins status will often still show a normalized version number for readability, the underlying data in manifest.json has changed. If you were parsing the manifest file directly, you'll need to adjust to use the tag key and expect the full tag string (potentially including the v).

✨ New Features

1. Pinning to Manifest with dotbins sync --pin-to-manifest:
   • A new --pin-to-manifest flag has been added to the sync command.
   • When used, dotbins sync will ignore the latest release information from GitHub and any tag specified in your dotbins.yaml. Instead, it will install the exact tag recorded for each tool in your manifest.json file.
   • Use Case: This is incredibly useful for ensuring reproducibility across environments or CI/CD pipelines. By committing your manifest.json to version control, you can guarantee that dotbins sync --pin-to-manifest always installs the same tool versions everywhere, regardless of newer releases on GitHub.
   • Example:

     # Ensure installed tools match the versions in manifest.json exactly
     dotbins sync --pin-to-manifest

⬆️ Migration

1. Run any dotbins command (e.g., dotbins sync, dotbins status) with v2.0.0 installed.
2. The tool will automatically detect versions.json, log a warning about the conversion, create manifest.json with the updated format, and delete versions.json.
3. If you track your ~/.dotbins directory (or your custom tools_dir) in Git, commit the new manifest.json file.
4. Review the output of your first dotbins sync run after upgrading, as some tools might be re-downloaded due to the manifest format changes.

PR list

• fix(nushell): Correct integration script generation for compatibility (#104) @basnijholt
• Add --pin-to-manifest (#103) @basnijholt
• Store URL in manifest.json (#101) @basnijholt
• Feat: Store exact tags in Manifest for reproducibility and support {tag} pattern (#98) @basnijholt

I believe these changes make dotbins a more robust and predictable tool for managing your CLI binaries within your dotfiles workflow. Thank you for using dotbins! Please report any issues or provide feedback on the GitHub repository.

dotbins v2.0.0 Release Notes 🎉

This is a major release for dotbins, introducing significant improvements to version tracking, reproducibility, and internal consistency. The core changes revolve around a more robust manifest system and the ability to pin tool installations precisely to your manifest file.

💥 Breaking Changes

1. versions.json Renamed to manifest.json:

   • The file used to track installed tool versions, previously named versions.json, has been renamed to manifest.json. This name better reflects its purpose and aligns with common terminology.
   • Migration: dotbins v2.0.0 will automatically detect an existing versions.json on the first run and convert it to the new manifest.json format, deleting the old file.
   • Impact: If you were manually interacting with versions.json or tracking it in Git, you will need to update your workflows to use manifest.json. Please commit the new manifest.json after the first run. Due to the automatic conversion and internal changes, the first sync after upgrading might result in some tools being re-downloaded.

2. Internal Version Tracking Changed to Store Full "Tag":

   • Previously, the manifest stored a normalized version string, often removing the leading v (e.g., 1.2.3). It now stores the exact Git tag as it appears on GitHub (e.g., v1.2.3 or 1.2.3) under the key tag.
   • Reason: This change is essential for ensuring dotbins can reliably re-download the exact same release specified by the tag. GitHub release tags are not always consistent (some use a v prefix, others don't). Storing the precise tag allows dotbins to request the correct release from the GitHub API, which is crucial for features like sync --pin-to-manifest and when using the tag parameter in your dotbins.yaml.
   • Impact: While display commands like dotbins status will often still show a normalized version number for readability, the underlying data in manifest.json has changed. If you were parsing the manifest file directly, you'll need to adjust to use the tag key and expect the full tag string (potentially including the v).

✨ New Features

1. Pinning to Manifest with dotbins sync --pin-to-manifest:
   • A new --pin-to-manifest flag has been added to the sync command.
   • When used, dotbins sync will ignore the latest release information from GitHub and any tag specified in your dotbins.yaml. Instead, it will install the exact tag recorded for each tool in your manifest.json file.
   • Use Case: This is incredibly useful for ensuring reproducibility across environments or CI/CD pipelines. By committing your manifest.json to version control, you can guarantee that dotbins sync --pin-to-manifest always installs the same tool versions everywhere, regardless of newer releases on GitHub.
   • Example:

     # Ensure installed tools match the versions in manifest.json exactly
     dotbins sync --pin-to-manifest

⬆️ Migration

1. Run any dotbins command (e.g., dotbins sync, dotbins status) with v2.0.0 installed.
2. The tool will automatically detect versions.json, log a warning about the conversion, create manifest.json with the updated format, and delete versions.json.
3. If you track your ~/.dotbins directory (or your custom tools_dir) in Git, commit the new manifest.json file.
4. Review the output of your first dotbins sync run after upgrading, as some tools might be re-downloaded due to the manifest format changes.

PR list

• fix(nushell): Correct integration script generation for compatibility (#104) @basnijholt
• Add --pin-to-manifest (#103) @basnijholt
• Store URL in manifest.json (#101) @basnijholt
• Feat: Store exact tags in Manifest for reproducibility and support {tag} pattern (#98) @basnijholt

I believe these changes make dotbins a more robust and predictable tool for managing your CLI binaries within your dotfiles workflow. Thank you for using dotbins! Please report any issues or provide feedback on the GitHub repository.

What's Changed

• Find perfect match by @basnijholt in #97

Full Changelog: v1.4.0...v1.5.0

What’s Changed

• Allow dotbins get --tag (#96) @basnijholt

What’s Changed

• fix: Prevent race condition with identical asset downloads (#95) @basnijholt

What’s Changed

• feat: Enhance shell_code configuration with comma-separated keys and __DOTBINS_SHELL__ placeholder (#94) @basnijholt
• Add logo to README.md (#93) @basnijholt

What’s Changed

• Make tag latest special (#92) @basnijholt
• Document tag parameter (#91) @basnijholt
• Add support to specify the version/release tag (#90) @basnijholt