版本号重定义

[xijing21]

鉴于之前由于没有约定版本号，导致目前版本号不统一的问题，进行统一化规定和约束，并统一进行修订。

Draft

早期的内部敏捷推进阶段

当前以积极探索为主，代码规范程度、成熟度、稳定些、兼容性都可能有所欠缺，主要以功能为主进行推进

版本号定义需求:

1. 双周版本：为了体现插件是否在某个双周迭代周期有发布新版本的一个更迭代号。以0.0.X为格式规范。每发布一次X加一；（其实觉得0.X.0 可能更合适，但是前期已经定义为0.0.X，也就是一个自增代号，没有修改的必要性，就先保持原定义）
2. jar版本：由于目前的插件工程中采用模块化解耦的思路，按照功能拆分成很多插件工程，每个工程发布时候都是一个独立的jar，为了标记这些jar的是否有代码变化，每个jar都需要独立的版本号。

 - A.B.C：主版本.功能变更.代码变更
   - 主版本A：目前未正式宣发正式版本之前，全部为0
   - 使用最后一位数字表示代码变更：
   - 无代码变化：版本不变
   - 有修改但无功能变化：仅增加最后一位（如0.1.1→0.1.2）
   - 新增功能：增加中间位（如0.1.2→0.2.0）

当前调整：

• 双周版本：接之前的版本号递增
• jar版本号：全部重置为 0.1.0，从这个版本开始，按照上述的规则进行编号处理；

长期规划

在完善构建之后，插件最终将打包到IDE中；并同时提供独立的jar包下载安装；

• IDE版本：采用Eclipse的版本号；比如fork自哪个Eclipse版本，就用Eclipse的版本号命名版本（一般为 202503 之类）；
• 插件版本（jar包）：主版本.次版本.修订号(MAJOR.MINOR.PATCH)
  • 正式发布后，从 1.0.0 开始重新编号
  • 主版本：不兼容的API更改
  • 次版本：向后兼容的功能新增
  • 修订号：向后兼容的问题修正
• 双周版本：看是否需要取消？

[xijing21]

Vendor ：供应商填什么？