Requests for Comments provide the durable record for significant Cretes changes. RFC 0001 (Phase 2 architecture) was accepted on 2026-10-10. Phase 3 is in final comment through 2026-10-19 inclusive UTC, with no decision before 2026-10-20 00:00 UTC. Acceptance, implementation and release are separate statuses.
Use an RFC for language semantics, type or memory models, concurrency, public interfaces, compatibility policy, major runtime/compiler architecture and governance changes. Small bug fixes and editorial corrections may use ordinary issues and pull requests.
- Open an issue describing the problem and check for related proposals.
- Copy TEMPLATE.md into
proposals/0000-short-title.mdon a branch. Use 0000 until a maintainer assigns the next unused number; numbers are never reused. - Submit a pull request. Complete motivation, design, alternatives, compatibility, safety and validation sections. Clearly mark sketches as unimplemented.
- Discuss tradeoffs publicly. Update the proposal as review progresses.
- The lead announces a final-comment period of at least seven calendar days, states the intended outcome and addresses outstanding objections.
- Record Accepted, Rejected or Deferred with date, rationale and links. Keep rejected/deferred history accessible; merge it as a decision record when useful.
- For an accepted proposal, link separate specification, implementation, test and release tracking. Acceptance does not mean implementation or release.
Draft → Review → Final comment → Accepted / Rejected / Deferred.
Accepted proposals may later become Superseded or Withdrawn with a linked decision. Track implementation separately as Not started, In progress, Implemented or Released. Do not silently edit a decided RFC to change meaning; use a follow-up RFC.
Current lead: @krishanth7. Follow the single-maintainer review policy in governance. Security vulnerability details belong in private reporting, not public RFCs.
Initial maintainer: @krishanth7. License: Apache-2.0.