Reopening after messing up #288.
## Motivation
The current version detection logic assumes that mods using
`automatic-version-check` either:
1. Use GitHub's automatic latest release URL
(`releases/latest/download/mod.zip`)
2. Link directly to repository HEAD (`archive/refs/heads/main.zip`)
However, some mod authors, like me, use **permanent release tag URLs**
like `releases/download/mod-name__latest/mod.zip` to provide stable
download links while still updating the underlying release. This pattern
is particularly common in **monorepos** where multiple mods share a
single repository.
## Problem
When a mod uses a permanent tag URL, the current script queries the
repository's overall latest release, which fundamentally diverge from
how releases in a monorepo work. This causes issues where:
- **All mods get the same version**: Every mod gets versioned as
whatever release was created most recently across the entire repository
- **False update notifications**: BMM detects "updates" when unrelated
mods are released
- **Broken update detection**: Actual updates to specific mods may not
be detected
## Solution
This PR adds support for permanent release tag URLs with minimal changes
by:
1. **Detecting the pattern**: URLs matching
`releases/download/{tag}/{asset}` or `releases/tag/{tag}` (excluding
`releases/latest/`)
2. **Querying specific tags**: Instead of `/releases/latest`, query
`/releases/tags/{specific-tag}`
3. **Using asset timestamps**: Generate versions based on the most
recent asset's `created_at` timestamp, this avoids generating updates
for simple renames in the asset.
4. **Maintaining compatibility**: All existing URL patterns continue to
work unchanged
### Key Design Decisions
- **Asset-agnostic**: Uses the most recently created asset instead of
searching for specific filenames, keeping it simple and efficient
- **Timestamp-based versioning**: Format `YYYYMMDD_HHMMSS` provides
human-readable, sequential versions
## Benefits
- **Enables monorepo workflows**: Authors can maintain multiple mods in
one repository with reliable update detection by updating specific tags
assets
- **Broader ecosystem support**: Works with any permanent tag naming
convention
- **Zero breaking changes**: Existing single-mod repositories continue
working identically
## Example
**Before**: All mods in `/balatro-mods` get version
`rebalanced-stakes__v1.2.8` (latest across entire repo)
**After**:
- `qol-bundle` gets version `20240115_103042` (when `qol-bundle__latest`
tag has new asset)
- `rebalanced-stakes` gets version `20240116_140521` (when
`rebalanced-stakes__latest` tag has new asset)
This enables reliable update detection for each mod independently.
## Considerations
The `update_mod_versions` script currently uses the `created_at`
timestamp of the most recent asset to generate versions. This approach
is intentionally flexible and works with various ways of updating fixed
release tags, but it may be worth considering more opinionated
approaches in the future. For example, we could require semantic
versioning in release titles or extract changelogs from release bodies,
which would open up possibilities for additional features.
This implementation can also be extended to latest-release URLs with
little effort, since they just redirect to a specific release tag in the
API. Any future metadata extraction features could apply to both URL
patterns.
For now, this PR focuses on providing immediate compatibility with
minimal friction in the existing environment, while establishing a
foundation that can be built upon later.
BMM won't detect updates if the version is None. Since the previous schema required version to be None when using `fixed-release-tag-updates`, that meant that manual updates via PR wouldn't be detected.
