Skip to content

Commit f5e2c18

Browse files
author
singi.qin
committed
feat: 日历化版本管理
1 parent 05af905 commit f5e2c18

File tree

8 files changed

+177
-50
lines changed

8 files changed

+177
-50
lines changed

blog/2025-07-08-php8_x.md/index.md renamed to blog/2025-07-08-php8_x.md

File renamed without changes.

blog/2025-07-09-laravel9模型关联.md/index.md renamed to blog/2025-07-09-laravel9模型关联.md

File renamed without changes.

blog/2025-12-01-Lighthouse.md/index.md renamed to blog/2025-12-01-Lighthouse.md

File renamed without changes.

‎blog/tags.yml‎

Lines changed: 6 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -26,4 +26,9 @@ Lighthouse:
2626
Web性能优化:
2727
label: Web性能优化
2828
permalink: /Web性能优化
29-
description: Web性能优化
29+
description: Web性能优化
30+
31+
版本管理:
32+
label: 版本管理
33+
permalink: /版本管理
34+
description: 版本管理

‎blog/日历化版本的优缺点.md‎

Lines changed: 116 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,116 @@
1+
---
2+
slug: 日历化版本
3+
title: 日历化版本的优缺点
4+
authors: [singi]
5+
tags: [版本管理]
6+
---
7+
8+
## 优点
9+
10+
日历化版本 (CalVer) 通过将版本号与时间绑定，实现了 "版本即时间，时间即价值" 的理念。它超越了传统版本号的简单标识功能，成为团队协作的时间轴、用户决策的参考点和产品生命周期的管理工具，特别适合当今快速迭代的软件开发环境。
11+
12+
若你的项目追求透明性、可预测性和高效协作，CalVer 值得认真考虑。
13+
14+
### 直观易懂，一见即知
15+
16+
版本号直接反映发布时间 (如2024.10表示 2024 年 10 月)，无需文档解释
17+
普通人也能立即判断版本新旧，无需理解复杂的数字规则
18+
特别适合面向终端用户的产品，提升用户体验
19+
20+
### 规划透明，协作增效
21+
22+
团队和用户可通过版本号直接掌握发布节奏 (如24.4.0表示 Q2 发布)
23+
使软件发布与业务时间表 (如财季、促销节点) 无缝对齐
24+
便于客户预期管理：可根据月份预判版本包含的季度功能
25+
减少沟通成本，使跨团队协作更高效
26+
27+
### 时间维度，价值倍增
28+
29+
历史追溯：一眼定位版本发布时间，便于问题排查和审计
30+
维护状态判断：开发者评估依赖库时，版本号直接反映维护活跃度
31+
生命周期管理：可实现 "日期驱动的弃用策略"，明确版本支持期限
32+
例如：Ubuntu 的20.04版本明确提供 5 年支持，用户可据此规划升级
33+
34+
### 技术优势，开发利器
35+
36+
冲突自动规避：时间戳天然唯一，避免并行开发的版本号冲突
37+
排序简便：版本号按时间自然排序，无需额外算法
38+
自动化友好：构建脚本可轻松实现版本号自动生成，减少人工错误
39+
特别适合高频发布场景 (如 Web 应用、SaaS 平台)，大幅提升交付效率
40+
41+
### 生态适配，降低成本
42+
43+
减少版本管理的认知负担，尤其适合大型团队和复杂项目
44+
与持续集成 / 持续部署 (CI/CD) 管道完美集成，加速交付周期
45+
可与语义化版本结合，形成混合方案 (如YYYY.MINOR.PATCH)，兼顾时间与功能
46+
对开源项目特别有益：贡献者和用户能快速评估项目活跃度
47+
48+
#### 适用场景速览
49+
50+
场景|优势体现
51+
-|-
52+
企业软件 (固定发布周期)|与业务节奏对齐，客户清晰掌握升级路径
53+
SaaS 平台 (持续迭代)|版本更新频率与用户预期匹配
54+
操作系统 (长周期支持)|明确标识支持期限，便于用户规划
55+
浏览器 / 工具类应用|直观展示更新活跃度，增强用户信任
56+
内部系统 (高频发布)|简化版本管理，提升团队协作效率
57+
58+
## 缺点
59+
60+
### 功能与兼容性信息缺失（最致命缺点）
61+
62+
CalVer 完全抛弃了版本号对 “功能变更类型” 的语义标识，而这恰恰是软件协作和依赖管理的关键：
63+
64+
- 无法判断升级风险：用户无法从版本号（如 2024.10 → 2024.11）中得知是否包含破坏性变更（比如 API 删除、参数修改）、新增功能还是仅修复 bug—— 这对依赖该项目的开发者来说是致命的，可能导致 “无意识升级” 引发生产环境故障。
65+
- 功能增量不透明：即使两个版本间隔 1 个月，也无法判断是 “小修小补” 还是 “重大重构”。例如：2024.9 可能仅修复 1 个 bug，2024.10 却重写了核心模块，但版本号无法体现这种差异。
66+
- 对比 SemVer 的劣势：语义化版本（SemVer）通过 MAJOR.MINOR.PATCH 明确区分 “不兼容变更 / 新功能 /bug 修复”，而 CalVer 必须依赖 Release Notes 才能获取这些信息，大幅增加了沟通和验证成本。
67+
68+
### 版本号粒度混乱，缺乏统一标准
69+
70+
CalVer 没有强制统一的版本格式（官方仅提供 “推荐方案”），导致不同项目的版本号规则五花八门，增加了认知负担：
71+
72+
- 格式碎片化：常见格式包括 YYYY.MM（如 Ubuntu 20.04）、YY.MINOR（如 PyPI 某些包）、YYYY.MM.PATCH（如 Terraform 0.12.0 后转向混合方案）、YYYY.MM.DD（如每日构建版本）—— 跨项目协作时，需要额外学习每个项目的版本规则。
73+
- 高频发布导致版本膨胀：对于每日迭代的 SaaS 产品或内部系统，若使用 YYYY.MM.DD 格式，版本号会快速变成 2024.10.28、2024.10.29，冗长且难以记忆；若简化为 YYYY.MINOR，则无法区分同一月份内的多次 bug 修复。
74+
- 低频率发布导致版本 “断层”：对于半年 / 一年发布一次的项目（如某些工具类开源库），版本号会出现大跨度跳跃（如 2023.1 → 2024.1），用户无法从版本号判断中间是否有重要更新，甚至误以为项目已停止维护。
75+
76+
### 迭代节奏受时间绑架，易引发质量问题
77+
78+
CalVer 将版本发布与时间强绑定，可能导致团队为了 “凑时间节点” 而牺牲软件质量：
79+
80+
- 仓促发布压力：若团队承诺 “每月发布一个版本”（如 2024.10、2024.11），即使功能未完成或测试不充分，也可能为了维持版本号的时间连续性而强行发布，导致线上 bug 增多。
81+
- 无意义版本泛滥：某些月份可能仅修复了 1-2 个微小 bug，却需要发布一个全新的 “月度版本”（如 2024.12），既浪费发布资源，也会让用户对 “版本更新” 产生麻木感（频繁更新但无实质价值）。
82+
- 无法灵活调整迭代周期：若业务需求变化导致需要延长 / 缩短发布周期（如从月度改为双周），版本号会出现逻辑混乱（如 2024.10 后直接跳到 2024.10.1），破坏用户对版本节奏的预期。
83+
84+
### 不适合长周期维护与向后兼容场景
85+
86+
现有软件生态（包管理器、CI/CD 工具、监控系统）大多是为 SemVer 设计的，CalVer 可能面临兼容性问题：
87+
88+
- 包管理器解析异常：npm、pip、Maven 等工具默认支持 SemVer 的 “版本范围匹配”（如 ^1.2.0 表示兼容 1.x.x 所有版本），但 CalVer 无统一的 “兼容性规则”—— 若项目用 2024.10 表示月度版本，用户无法通过版本范围快速锁定 “兼容的旧版本”，只能手动指定具体版本号。
89+
- CI/CD 自动化适配复杂：部分自动化工具（如自动更新依赖的脚本、版本对比工具）依赖 SemVer 的语义规则判断 “是否需要升级”，而 CalVer 只能通过时间戳判断新旧，可能导致 “不必要的升级”（如从 2024.10 自动升级到 2024.11，但后者包含破坏性变更）。
90+
- 跨版本协作沟通成本高：若团队中部分项目用 CalVer，部分用 SemVer，跨项目依赖时需要额外对齐版本规则 —— 例如：A 项目（CalVer 2024.10）依赖 B 项目（SemVer 2.3.0），开发者需要同时理解两套版本逻辑，容易出错。
91+
92+
### 用户认知与信任度问题
93+
94+
CalVer 的版本号对普通用户（尤其是非技术用户）不够友好，甚至可能影响产品信任度：
95+
96+
- 版本 “新旧” 判断反直觉：对于低频更新的产品，用户可能误以为 “版本号越新（时间越近）功能越全”，但实际可能只是修复了 bug；反之，某些旧版本（如 2023.06）可能比新版本（2024.01）更稳定，但用户会倾向于选择 “时间更新” 的版本，导致不必要的升级风险。
97+
- 项目活跃度误判：开源项目若长时间未发布新版本（如 2022.01 后无更新），用户会通过版本号直接判断 “项目已死”，但实际可能是团队在专注维护旧版本或开发重大功能 —— 而 SemVer 中，1.2.3 之后即使隔两年发布 1.3.0，用户也能理解是 “功能迭代” 而非 “项目复活”。
98+
- 企业客户决策困难：企业客户采购软件时，通常会关注 “版本稳定性” 和 “支持周期”，但 CalVer 无法从版本号中体现这些信息 —— 例如：2024.10 可能是刚发布的不稳定版本，而 2023.06 是经过长期验证的稳定版，但客户可能更倾向于选择 “时间更新” 的版本，导致决策失误。
99+
100+
#### 适用场景速览
101+
102+
应用场景|CalVer 缺点体现
103+
-|-
104+
开源依赖库（供他人依赖）|无法标识破坏性变更，导致依赖方升级故障；包管理器适配差，依赖解析复杂
105+
企业级 API 服务|兼容性信息不透明，客户端升级风险高；LTS 版本标识模糊，客户难以规划长期使用
106+
低频更新的工具类软件|版本号断层，用户误判项目活跃度；无意义版本泛滥，降低用户信任度
107+
需严格质量管控的软件|时间节点压力导致仓促发布，质量下降；bug 修复需要发布 “月度版本”，资源浪费
108+
跨团队协作的大型项目|版本规则不统一，认知成本高；跨项目依赖时，版本逻辑冲突
109+
110+
## 总结
111+
112+
CalVer 的核心矛盾是 “时间优先” 与 “软件语义需求” 的冲突 —— 它将版本号的核心功能从 “描述软件状态” 扭曲为 “标记发布时间”，导致版本号失去了对 “功能、兼容性、稳定性” 的标识作用。
113+
114+
这些缺点并非 “不可缓解”（例如通过 “CalVer + 语义后缀” 混合方案：2024.10.1 表示 2024 年 10 月第 1 个补丁版，2024.11-beta 表示测试版），但无法从根本上解决 —— 混合方案本质上是向 SemVer 妥协，反而增加了版本规则的复杂性。
115+
116+
因此，CalVer 更适合 “**不依赖他人、用户直接使用、快速迭代、无需严格兼容性承诺**” 的场景（如 SaaS 平台、内部系统、消费级 App），而在 “**供他人依赖、需要长期支持、严格兼容性保障**” 的场景中，SemVer 依然是更稳妥的选择。

‎docusaurus.config.ts‎

Lines changed: 34 additions & 42 deletions
Original file line numberDiff line numberDiff line change
@@ -49,7 +49,7 @@ const config: Config = {
4949
// Please change this to your repo.
5050
// Remove this to remove the "edit this page" links.
5151
editUrl:
52-
'https://github.com/facebook/docusaurus/tree/main/packages/create-docusaurus/templates/shared/',
52+
'https://github.com/singi2016cn/singi2016cn.github.io',
5353
},
5454
blog: {
5555
showReadingTime: true,
@@ -60,7 +60,7 @@ const config: Config = {
6060
// Please change this to your repo.
6161
// Remove this to remove the "edit this page" links.
6262
editUrl:
63-
'https://github.com/facebook/docusaurus/tree/main/packages/create-docusaurus/templates/shared/',
63+
'https://github.com/singi2016cn/singi2016cn.github.io',
6464
// Useful options to enforce blogging best practices
6565
onInlineTags: 'warn',
6666
onInlineAuthors: 'warn',
@@ -83,15 +83,15 @@ const config: Config = {
8383
src: 'img/logo.svg',
8484
},
8585
items: [
86-
// {
87-
// type: 'docSidebar',
88-
// sidebarId: 'tutorialSidebar',
89-
// position: 'left',
90-
// label: 'Tutorial',
91-
// },
92-
{to: '/blog', label: 'Blog', position: 'left'},
9386
{
94-
href: 'https://github.com/facebook/docusaurus',
87+
type: 'docSidebar',
88+
sidebarId: 'tutorialSidebar',
89+
position: 'left',
90+
label: '指南',
91+
},
92+
{to: '/blog', label: '博客', position: 'left'},
93+
{
94+
href: 'https://github.com/singi2016cn',
9595
label: 'GitHub',
9696
position: 'right',
9797
},
@@ -100,43 +100,35 @@ const config: Config = {
100100
footer: {
101101
style: 'dark',
102102
links: [
103-
// {
104-
// title: 'Docs',
105-
// items: [
106-
// {
107-
// label: 'Tutorial',
108-
// to: '/docs/intro',
109-
// },
110-
// ],
111-
// },
112-
// {
113-
// title: 'Community',
114-
// items: [
115-
// {
116-
// label: 'Stack Overflow',
117-
// href: 'https://stackoverflow.com/questions/tagged/docusaurus',
118-
// },
119-
// {
120-
// label: 'Discord',
121-
// href: 'https://discordapp.com/invite/docusaurus',
122-
// },
123-
// {
124-
// label: 'X',
125-
// href: 'https://x.com/docusaurus',
126-
// },
127-
// ],
128-
// },
129103
{
130-
title: 'More',
104+
title: '文档',
105+
items: [
106+
{
107+
label: '指南',
108+
to: '/docs/intro',
109+
},
110+
],
111+
},
112+
{
113+
title: 'Community',
131114
items: [
132115
{
133-
label: 'Blog',
116+
label: 'Bilibili',
117+
href: 'https://stackoverflow.com/questions/tagged/docusaurus',
118+
},
119+
],
120+
},
121+
{
122+
title: '更多',
123+
items: [
124+
{
125+
label: '博客',
134126
to: '/blog',
135127
},
136-
// {
137-
// label: 'GitHub',
138-
// href: 'https://github.com/facebook/docusaurus',
139-
// },
128+
{
129+
label: 'GitHub',
130+
href: 'https://github.com/singi2016cn',
131+
},
140132
],
141133
},
142134
],

‎src/pages/markdown-page.md‎

Lines changed: 0 additions & 7 deletions
This file was deleted.

‎src/pages/singi/index.js‎

Lines changed: 21 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,21 @@
1+
import React from 'react';
2+
import Layout from '@theme/Layout';
3+
4+
export default function Hello() {
5+
return (
6+
<Layout title="Hello" description="Hello React Page">
7+
<div
8+
style={{
9+
display: 'flex',
10+
justifyContent: 'center',
11+
alignItems: 'center',
12+
height: '50vh',
13+
fontSize: '20px',
14+
}}>
15+
<p>
16+
Edit <code>pages/helloReact.js</code> and save to reload.
17+
</p>
18+
</div>
19+
</Layout>
20+
);
21+
}

0 commit comments

Comments
 (0)