Semver: handle prerelease comparison
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 74/100
Research direction
Start at translator._semver_sort_key_expr and inspect the existing semver_sort_key behavior and its callers. Verify that versions such as 1.2.3-beta sort before 1.2.3, while build metadata does not affect the prerelease portion; done means the documented mismatch is corrected without requiring numeric prerelease-segment comparison.
Written by the indexing model from the issue text.
Description
semver_sort_key (in translator._semver_sort_key_expr) extracts the first three digit-runs from the version string, zero-pads each to 10 chars, and joins with dots. This gives correct major.minor.patch ordering but ignores prerelease: 1.2.3-beta and 1.2.3 produce the same key.
Per semver spec, 1.2.3-beta < 1.2.3 (prerelease versions compare less than the corresponding release). My current implementation gets this wrong.
What to ship
Extend the sort key with a prerelease tail. Approximation that's good enough for behavioural-targeting use:
- Extract everything after
-(and before any+build metadata) as the prerelease string. - Append a sentinel:
'~'for absent prerelease (sorts after any prerelease alphabetically —~is high-ASCII), the literal prerelease string otherwise. - Per-dot-segment numeric prerelease comparison is a further refinement (engine semver lib does this); skip for v1.
Why deferred
Smoke-tested at 23/24 parity in the PoC; the one mismatch was the prerelease case described above. Customer segments using semver tend to use clean major.minor.patch (app_version: "2.5.10") without prerelease tails. Will revisit if a customer reports an unexpected match for a -beta version.
- Dominant language
- Python
- Stars
- 1
- Forks
- 0
- PR merge metrics
- No merged PRs in 30d
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from Flagsmith/flagsmith-sql-flag-engine
-
Dependency Dashboard Open
Difficulty 4/5 3-5 days Newbie friendliness 15/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 35/100
-
Difficulty 3/5 1-2 days Newbie friendliness 48/100
-
Difficulty 5/5 Over a week Newbie friendliness 45/100
Flagsmith/flagsmith-sql-flag-engine#3 · 1 comment ·
-
Difficulty 5/5 Over a week Newbie friendliness 35/100
All issues in Flagsmith/flagsmith-sql-flag-engine
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
syfoud/Simulated_Scepter#172 ·
-
A cancelled tests run makes the coverage comment workflow fail and reports it as a red check on main Openarea: ci bug perceived difficulty: 3
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Nitjsefnie-Harness-Commons/daedalus#921 · 1 comment ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
EleutherAI/lm-evaluation-harness#4207 ·
-
Difficulty 1/5 Under an hour Newbie friendliness 92/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
ClickHouse/clickhouse-connect#1057 ·