Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
fix: handle General/Complex Versioning in --bump (#2889)
* fix: handle General/Complex Versioning in --bump The previous fix to handle non-semver versions in `--bump` used a crude heuristic - a check whether there's a "." in the version string - to decide whether to attempt to `chunkify` or just fall back to returning the new version unmodified. This, however, resulted in no bump happening (`None` returned from `check_semver_bump`) when either of the old/new versions looked like "v1.2.3". Additionally, versions like "1.2a1" and "1.2a2" were considered the same, because: a) the heuristic failed to recognise they won't be parsed/chunkified correctly, and b) `chunkify` used `nth` that silently throws parts of the version away. I'm proposing to fix this by reimplementing `chunkify` using the much more generic versions::Mess format, which simply splits the version number into chunks and separators. We then convert it into a simpler format of just chunks (first chunk as is, further chunks with a separator prepended). This design has an issue: we don't recognise a change in the versioning scheme. A bump from "<commit sha>" to "v1.2.3" will result in just "v1", because the commit sha is parsed as a single chunk. The most obvious case of this, "latest" being parsed as a single chunk, is handled explicitly in the code, as it would just be a mess otherwise. A potential workaround for this issue would be to add a flag (e.g. `--pin`) that would make `--bump` skip the `check_semver_bump` logic and always use the full new version (as suggested in #2704 (comment)). This would also help in the following case: a project using variable length version numbers instead of the full 3-chunk semver. Trying to follow this sequence of bumps: "20.0", "20.0.1", "20.1" isn't possible with the current logic. Related: 0b2c2aa ("fix: upgrade --bump with non-semver versions (#2809)") * fix: Allow --bump from 20.0.1 to 20.1 It's weird so we still warn, but returning `None` from `check_semver_bump` only makes sense if the versions are deemed to be the same. Otherwise it's just confusion for the user — the UI presents this as an upgrade, proceeds to uninstall the old version, but fails to do the actual bump and no new version is installed. * fix: handle prefix: versions --------- Co-authored-by: jdx <[email protected]>
- Loading branch information