fix(release): make dev packages post-stable

[krishicks]

Summary

Dev releases now use post-stable package versions in tasks/scripts/release.py:99:

Python: 0.0.37.post108+g152d05940
Cargo: 0.0.37+post.108.g152d05940
Debian: 0.0.37+post.108.g152d05940-1
RPM: Version 0.0.37, Release 2.dev.108.g152d05940

That makes dev sort after the latest stable 0.0.37-1, while still sorting below the next stable 0.0.38-1.

This allows us to do an upgrade installation from a stable release to a dev release, but then still be able to upgrade that dev release to the next stable release.

Related Issue

Changes

• Use base_version (current stable) instead of _next_patch(base_version) for dev builds
• Switch Python version suffix from .dev{n} to .post{n} (PEP 440 post-release)
• Update Cargo regex: .post{n}+g{sha} → +post.{n}.g{sha} (build metadata, not pre-release)
• Change RPM release prefix from 0.dev. to 2.dev. so it sorts after stable release 1
• Remove Debian ~dev. substitution (no longer needed with +post. format)

Testing

• mise run pre-commit passes
• Unit tests added/updated
• E2E tests added/updated (if applicable)

Checklist

• Follows Conventional Commits
• Commits are signed off (DCO)
• Architecture docs updated (if applicable)

[elezar]

Why do the rpm releases not use post? Also: Was the switch from dev to post required?

[krishicks]

It maybe deemed it not necessary given

Change RPM release prefix from 0.dev. to 2.dev. so it sorts after stable release 1

I can look into it more.

[krishicks]

I explored this with Opus 4.8, and the reasoning seems solid:

---

Why ~dev → +post

A dev build must sort above the current stable so apt install -y treats it as an upgrade (CI doesn't pass --allow-downgrades). The old ~dev form sorted below its base version (~ sorts before everything), so installing dev on top of stable was rejected as a downgrade. +post sorts above the base, so:

0.0.37-1  <  0.0.37+post.108...-1  <  0.0.38-1
   stable        dev                  next stable

It's also the only form valid across all formats from one derived identity: PEP 440 has no "after X but before next" except .post (its .dev is a pre-release, same downgrade bug), and the Cargo/Docker/Debian strings are all derived from the Python version.

Why RPM doesn't get post

RPM splits version into two fields — Version and Release — and sorts by Version first, then Release. The Release field already does what .post does elsewhere:

Package	Version	Release
stable	0.0.37	1
dev	0.0.37	2.dev.108...
next stable	0.0.38	1

Bumping Release from 1 to 2.dev. puts dev after stable within the same Version, while 0.0.38 wins on Version. RPM has no .post concept and doesn't need one — the two-field scheme handles ordering natively.