VEP 1: VEP 目的与流程
VEP 1 — VEP 目的与流程
摘要
VEP（Vix Enhancement Proposal）是 Vix 语言社区提出、讨论和记录改进建议的标准化流程。本文档定义了 VEP 的目的、类型、生命周期以及提交规范。
动机
Vix 语言的发展需要一套清晰的决策机制。参考 Python PEP 的经验，VEP 流程旨在：
- 为语言演进提供透明的讨论渠道
- 保留设计决策的历史记录
- 让社区参与语言发展方向的选择
- 统一标准库、编译器和工具链的变更流程
VEP 的类型
每份 VEP 必须属于以下类型之一：
| 类型 | 说明 |
|---|---|
| 标准 | 语言语法、语义、标准库等核心变更 |
| 流程 | 围绕 Vix 开发流程的变更（如本提案） |
| 信息 | 设计指南、最佳实践、信息说明，不涉及功能变更 |
VEP 状态与生命周期
状态定义
| 状态 | 说明 |
|---|---|
| 草稿 | 正在编写和讨论中，尚未定型 |
| 已接受 | 核心团队认可方向，等待实现 |
| 已实现 | 提案内容已完成开发并合并 |
| 已拒绝 | 经讨论后被否决，不再推进 |
| 已撤回 | 提交者主动撤回，不再继续 |
| 终稿 | 已实现并稳定，不再修改 |
状态流转
┌─────────┐
│ 草稿 │
└────┬────┘
│
┌──────┼──────────┐
│ │ │
▼ ▼ ▼
┌──────┐ ┌────┐ ┌────────┐
│已接受│ │已拒绝│ │ 已撤回 │
└──┬───┘ └────┘ └────────┘
│
▼
┌────────┐
│已实现 │
└───┬────┘
│
▼
┌──────┐
│ 终稿 │
└──────┘
提交 VEP 的步骤
1. 前期准备
在开始撰写正式提案前，建议先在 GitHub Issues 发起讨论，收集社区反馈。
2. 编写提案
- Fork 本仓库
- 从
_veps/vep-0000.md复制模板 - 命名为
_veps/vep-<编号>.md - 填写 front matter 和正文
3. 提交 PR
将提案以 Pull Request 形式提交，状态标记为 草稿。
4. 讨论与评审
- 社区和核心团队在 PR 中提出修改意见
- 提交者根据反馈更新提案内容
- 讨论应在合理时间内完成
5. 决策
核心团队对提案做出最终决定：
- 接受 → 状态改为 已接受
- 拒绝 → 状态改为 已拒绝，并说明理由
6. 实现与终稿
- 提案实现后，状态改为 已实现
- 稳定运行后改为 终稿
编号规则
- VEP 编号按顺序分配，从 0 开始
- VEP 0 为索引提案
- VEP 1 为本提案（目的与流程）
- 已被拒绝的提案的编号不重复使用
格式规范
每份 VEP 必须包含以下 front matter：
---
vep: <编号>
title: <标题>
status: 草稿 | 已接受 | 已实现 | 已拒绝 | 已撤回 | 终稿
type: 标准 | 流程 | 信息
created: YYYY-MM-DD
updated: YYYY-MM-DD # 可选
author: <作者名> # 可选
---
元数据字段说明
| 字段 | 必填 | 说明 |
|---|---|---|
vep | 是 | 提案编号，整数 |
title | 是 | 提案标题，简明扼要 |
status | 是 | 当前状态，见状态定义 |
type | 是 | 提案类型，见VEP 的类型 |
created | 是 | 创建日期 |
updated | 否 | 最后更新日期 |
author | 否 | 提案作者 |
正文结构建议
- 使用 Markdown 编写
- 建议包含：摘要、动机、详细设计、兼容性考虑、参考文献等章节
- 复杂提案可包含图表（推荐使用 ASCII art 或 Mermaid 图表）