docs: document the draft-stage versioning rule#16
Conversation
While a spec is in Draft, the Version field doubles as a compatibility signal with current OVOS: - v1 = drop-in compatible - v2 = incompatible (requires OVOS-side changes) Compatible changes during draft fold into the current version rather than bumping. Only incompatible features bump. The rule applies only while a spec is in Draft; once promoted out of Draft, every normative change bumps the version per the standard rule. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
Warning Review limit reached
Your plan currently allows 1 review/hour. Refill in 33 minutes and 48 seconds. Your organization has run out of usage credits. Purchase more in the billing tab. ⌛ How to resolve this issue?After more review capacity refills, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than trial, open-source, and free plans. In all cases, review capacity refills continuously over time. Please see our FAQ for further information. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Summary
Document the policy that while a spec is in Draft, the Version
field doubles as a compatibility signal with current OVOS:
Compatible changes during draft fold into the current version
rather than bumping. Only incompatible features bump.
The applied consequences (already in their respective PRs):
Test plan
🤖 Generated with Claude Code