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.