Proposal: Moving iUWM to Semantic Versioning (SemVer)

[NotYoojun]

I’d like to start a conversation about adopting Semantic Versioning (SemVer) for this project.

Right now, our version numbers (e.g. 0.10.2) have been used more loosely to reflect development status and progress. But as more developers rely on this library, versioning becomes more than just a number - it’s a signal of stability, compatibility, and trust.

Here are some key points I’d like us to discuss together:

1. Is adopting SemVer really necessary?

Right now, our versioning has been milestone-driven and somewhat informal. As more developers adopt the library, predictability and clarity in versioning will help them understand whether an update is safe to apply or requires code changes.

Package managers (NuGet, etc.) also rely on consistent versioning to resolve dependencies correctly.

The question is: do we truly need to formalize this now, or can we continue with our current approach a bit longer (or, forever)?

• Pros: Clear communication of breaking changes, easier dependency management for downstream projects, aligns with ecosystem expectations.

• Cons: Adds overhead in release planning, may feel restrictive during rapid development, and could reduce flexibility in branding

2. Balancing technical versioning and branding

SemVer is strict: MAJOR.MINOR.PATCH.

Branding, however, sometimes benefits from signaling progress differently (e.g., 0.x for early development, or “1.0” as a milestone of maturity).

• Should we continue with 0.x until we feel the API is stable, or move toward a 1.0 release soon to reflect project maturity?

• How do we balance developer expectations with community perception?

3. Implementation and methods

• Adopt SemVer 2.0.0 as the standard.
• Maintain a CHANGELOG.md that clearly marks breaking changes, new features, and fixes.
• Consider using conventional commits or similar tooling to automate version bumps and changelog generation.
• Tag releases consistently in GitHub and NuGet.

4. When to start adapting

• Should we begin with the next release?

• Or should we wait until a major milestone (e.g., a stable API baseline) before declaring 1.0.0?

• Do we need to retroactively re-tag older releases, or just move forward from here?

5. Other important considerations

• Deprecation policy: How do we handle features that are being phased out? Should we mark them as obsolete before removing them in the next major release?

• Pre-release versions: Should we use -alpha, -beta, or -rc tags for experimental features?

• Documentation: Where should we document our versioning policy: README, CONTRIBUTING.md, or a dedicated VERSIONING.md?

---

💬 Call for feedback

I’d love to hear your thoughts INCLUDING BUT NOT LIMITED on:

• Do we really need to adapt to SemVers?

• How strict we should be about SemVer compliance

• When we should declare 1.0.0

• Whether contributors are open to adopting conventional commits or similar workflows

Your input will help shape a versioning strategy that’s clear, predictable, and sustainable for everyone 🚀

Thanks,
Yoojun Zhou (Project Owner)