olmOCR 版本发布全解析CHANGELOG 规范、版本时间线与自动化发布流程【免费下载链接】olmocrToolkit for linearizing PDFs for LLM datasets/training项目地址: https://gitcode.com/GitHub_Trending/ol/olmocr本文围绕 olmOCR 仓库中的 docs/source/CHANGELOG.md 展开系统解读这份变更日志所承载的版本演进信息并深入仓库源码梳理从版本号定义、CHANGELOG 维护到 git tag 与 GitHub Release 的全自动发布链路。读完本文你将掌握 olmOCR 自 2025 年 2 月至今的完整版本时间线、各重大里程碑背后的功能演进以及复现其发布流程所需的全部脚本与操作步骤。一、CHANGELOG 是什么一份遵循双规范的版本档案olmOCR 的 CHANGELOG 文件在仓库中以双份形式存在根目录的 CHANGELOG.md 与文档站点使用的 docs/source/CHANGELOG.md两者内容保持一致均为项目的官方变更日志。文件开头明确声明了它所遵循的两项行业规范Keep a Changelog 格式所有值得记录的变更都按版本分组、按时间倒序排列顶部保留## Unreleased区块用于存放尚未发布的新改动。Semantic Versioning语义化版本版本号遵循MAJOR.MINOR.PATCH三段式语义由 pyproject.toml 中dynamic [version]配置动态读取。从内容形态看这份 CHANGELOG 更像一份版本索引档案绝大多数条目只记录版本号 发布日期两要素如## [v0.4.27] - 2026-03-12而具体的功能明细被安排在 GitHub Release 页面。这一点从仓库的发布工具链可以得到印证scripts/release_notes.py 专门从 CHANGELOG.md 中抽取指定 TAG 的条目、重组为 GitHub Release Notes 的 Whats new 与 Commits 段落说明 CHANGELOG 是自动化发布体系的事实数据源。二、版本时间线从 0.1.x 到 0.4.x 的演进全景将 CHANGELOG 中记录的版本号与日期整理成时间线可以清晰看到 olmOCR 的发布节奏——版本号密度从早期的密集迭代逐步过渡到 0.4.x 时代的稳定节奏版本阶段时间跨度代表版本v0.1.x早期迭代2025-02 至 2025-06v0.1.53 → v0.1.76v0.2.x训练体系重构2025-07 至 2025-08v0.2.0 → v0.2.3v0.3.x模型与旋转修复2025-08 至 2025-10v0.3.0 → v0.3.9v0.4.x合成数据与 RL2025-10 至 2026-03v0.4.0 → v0.4.27最新当前仓库处于v0.4.27根目录 olmocr/version.py 中_MAJOR 0、_MINOR 4、_PATCH 27与 CHANGELOG 顶部最新条目完全对应而_PATCH注释还标注了一条工程约定——主干分支上的 patch 号应比上一次发布领先一位以便为 nightly 构建预留版本空间。值得注意的是时间线上的两个版本号跳跃v0.1.53之后直接跳到v0.1.582025-02-15v0.4.7之后跳到v0.4.92025-12-01 与 2025-12-09。这种跳跃在语义化版本实践中通常意味着被跳过的编号对应的发布在构建或校验环节失败后未对外保留标签或属于内部构建。CHANGELOG 忠实记录了最终对外保留的版本序列这一点也符合 scripts/release.sh 中失败发布需删除 tag 后重发的流程设计。三、重大版本里程碑解读版本号背后的功能演进CHANGELOG 中大多数条目为精简的版本占位但结合 README.md 的 News 栏目与 CHANGELOG 中极少数携带说明的条目可以还原出各重大版本的核心内涵1. v0.1.532025-02-14最早可查的版本条目这是 CHANGELOG 中记录的最早版本也是唯一带文字说明的早期条目Fixed git checks修复 git 检查Added gemini and claude runners and a viewer新增 Gemini 与 Claude 推理 runner以及文档查看器对应的 runner 实现在仓库中均有落地olmocr/bench/runners/run_gemini.py 与 olmocr/bench/runners/run_claude.pyviewer 则对应 olmocr/viewer/dolmaviewer.py 及其 HTML 模板用于浏览由 PDF 转换生成的 Dolma 文档。2. v0.1.582025-02-15初始公开发布紧随其后的 v0.1.58 是项目的首次公开亮相与 Demo 上线README News 明确标注 Initial public launch and demo。3. v0.1.602025-03-17采样策略优化本次版本带来性能改进核心在于采样温度选择的优化。这一工程细节在 olmocr/pipeline.py 中可见端倪TEMPERATURE_BY_ATTEMPT [0.1, 0.1, 0.2, 0.3, 0.5, 0.8, 0.9, 1.0]—— 每次重试尝试会逐步升高解码温度以帮助模型克服重复输出问题这正是 v0.1.60 所宣称的性能提升的底层机制。4. v0.1.682025-05-19olmOCR-Bench 基准发布发布 olmOCR-Bench 评测基准同时因提示词 bug 修复带来 pipeline 2 分的性能提升。基准套件位于 olmocr/bench覆盖 7000 测试用例、1400 文档README 中记录了当时 77.4 的基准得分。5. v0.1.702025-05-23官方 Docker 支持发布官方 Docker 镜像仓库内对应 Dockerfile 与 Dockerfile.with-model 两份构建配置后者内置约 30GB 模型权重。6. v0.1.752025-06-17推理引擎切换这是架构层面的关键变更从 sglang 切换到 vllm 推理管线并将 Docker 镜像升级至 CUDA 12.8。pyproject.toml 的gpu可选依赖中vllm0.11.2的固定版本约束正是这次切换的延续。7. v0.2.02025-07-23训练代码重构发布全新整理过的训练器代码显著降低自行训练 olmOCR 模型的门槛对应 olmocr/train 目录中的 train.pyQwen2.5-VL SFT 微调与 grpo_train.pyGRPO RL 训练器。8. v0.3.02025-08-13自动旋转检测与幻觉修复新模型发布核心修复两项能力自动旋转检测auto-rotation detection与空白文档上的幻觉问题。旋转相关的训练配置在 olmocr/train/configs/v0.3.0 中成系列出现rotation_1epoch / rotation_2epoch / rotation_augment 等可见旋转增强是该版本训练数据策略的重点。9. v0.4.02025-10-22合成数据 强化学习v0.4.0 是 0.4.x 时代的起点引入合成数据与 RL强化学习训练使 olmOCR-Bench 得分提升约 4 分。合成数据生成逻辑位于 olmocr/synth/mine_html_templates.pyRL 训练器即 olmocr/train/grpo_train.py仓库中还附带技术报告 olmOCR-2-Unit-Test-Rewards-for-Document-OCR.pdf说明 RL 阶段采用单元测试奖励机制。10. v0.4.9 ~ v0.4.27稳定迭代期2025 年 12 月至 2026 年 3 月间版本围绕推理稳定、依赖升级与缺陷修复持续迭代v0.4.27 是当前最新版本2026-03-12。四、版本号从哪来version.py 与动态版本注入olmOCR 的版本号只有一个事实来源olmocr/version.py其结构为_MAJOR 0 _MINOR 4 # On main and in a nightly release the patch should be one ahead of the last # released build. _PATCH 27 # This is mainly for nightly builds which have the suffix .dev$DATE. See # https://semver.org/#is-v123-a-semantic-version for the semantics. _SUFFIX VERSION_SHORT {0}.{1}.format(_MAJOR, _MINOR) VERSION {0}.{1}.{2}{3}.format(_MAJOR, _MINOR, _PATCH, _SUFFIX)要点解读三段式拼接VERSION MAJOR.MINOR.PATCH SUFFIX产出如0.4.27。nightly 支持_SUFFIX主要为夜间构建预留格式为.dev$DATE例如0.4.27.dev20260312符合语义化版本对预发布版本号的规定。patch 前置约定主干分支上的_PATCH应比上一个已发布版本领先一位保证随时可以出 nightly 而不与正式版冲突。该版本号通过 pyproject.toml 的[tool.setuptools.dynamic] version {attr olmocr.version.VERSION}注入 Python 包元数据并被 olmocr/pipeline.py 以from olmocr.version import VERSION的形式引用例如用于打点日志与统计形成一处定义、处处生效的单一事实源。五、发布流程解剖从版本号到 GitHub Release 的自动化链路CHANGELOG 中的每一条版本记录背后都有一条完整的自动化发布链路。仓库的 RELEASE_PROCESS.md 给出了人工操作的完整步骤而 scripts/release.sh、scripts/prepare_changelog.py 与 scripts/release_notes.py 则构成工具链主体。1. 人工准备RELEASE_PROCESS.md更新 olmocr/version.py 中的版本号运行发布脚本./scripts/release.sh脚本负责提交 CHANGELOG 与 version.py 的变更并创建 git tagtag 的创建会触发 GitHub Actions 工作流由工作流接管剩余发布动作构建、上传等。若发布失败需要修复后重发则须先删除远程 tag 与 Release再在本地执行git tag -l | xargs git tag -d git fetch -t清理本地残留然后重复上述步骤。2. release.sh版本一致性校验与提交scripts/release.sh 的核心逻辑通过正则从olmocr/version.py提取_MAJOR、_MINOR、_PATCH、_SUFFIX并拼出VERSION_PY用python -c from olmocr.version import VERSION; print(v VERSION)获取包内报告的版本TAG两者不一致时交互式询问是否继续提示先执行pip install -e .同步版本确认后依次执行python scripts/prepare_changelog.py→git add CHANGELOG.md→ commit消息固定为Bump version to $TAG for release→ push → 创建 tag →git push --tags。脚本使用set -e严格失败退出任何一步出错都会中断流程。3. prepare_changelog.py自动写入版本条目scripts/prepare_changelog.py 负责维护 CHANGELOG.md扫描文件找到## Unreleased区块在 Unreleased 之后、最旧版本之前插入形如## [v0.4.27](https://github.com/allenai/olmocr/releases/tag/v0.4.27) - 2026-03-12的新条目日期取自当前时间若对应版本条目已存在则直接提示 CHANGELOG already up-to-date 并退出保证幂等性找不到 Unreleased 区块时抛出RuntimeError终止发布。这正是 CHANGELOG 中每个版本条目的生成源头——解释了为何每条都遵循完全一致的版本号 链接 日期格式。4. release_notes.py生成 GitHub Release Notesscripts/release_notes.py 将 CHANGELOG 转换为最终对外发布的 Release Notes读取环境变量TAG解析 CHANGELOG.md 中对应版本段将### Added / Changed / Fixed / Removed小节映射为带 emoji 的标题/⚠️/✅/生成## Whats new段落通过git log {last_tag}..{TAG} --oneline --first-parent拉取两版本间的首父提交历史生成## Commits段落跳过## Unreleased区块确保只发布已定型内容。六、从 CHANGELOG 看工程实践给读者的三个启示版本即产品档案olmOCR 用CHANGELOG 索引 GitHub Release 明细的双层结构管理变更信息版本条目的统一格式由 scripts/prepare_changelog.py 自动化保证避免了人工维护的格式漂移。版本号单一事实源所有版本信息收敛于 olmocr/version.py并由 release 脚本做双重校验杜绝包版本与 tag 不一致这类发布事故。可追溯的演进脉络通过对照 CHANGELOG 时间线与 README.md 的 News、olmocr/train/configs 下 v0.2.0 / v0.3.0 / v0.4.0 / v0.5.0 的配置目录演进读者可以完整还原基准发布 → Docker 支持 → 引擎切换 → 训练重构 → 旋转修复 → 合成数据与 RL的技术发展主线v0.5.0 配置目录已出现在 olmocr/train/configs/v0.5.0预示着下一阶段围绕 GRPO 与多模型Qwen3-VL 等的迭代方向。对于希望深入理解或复刻这套发布体系的开发者建议按如下顺序阅读仓库先通读 CHANGELOG.md 建立版本全局观再对照 RELEASE_PROCESS.md 与 scripts/release.sh 理解自动化链路最后结合 olmocr/version.py 与 pyproject.toml 掌握版本号的生成与注入机制——这份 CHANGELOG 不仅是变更记录更是理解整个项目工程化水平的入口。【免费下载链接】olmocrToolkit for linearizing PDFs for LLM datasets/training项目地址: https://gitcode.com/GitHub_Trending/ol/olmocr创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 olmOCR 版本发布全解析：CHANGELOG 规范、版本时间线与自动化发布流程
olmOCR 版本发布全解析CHANGELOG 规范、版本时间线与自动化发布流程【免费下载链接】olmocrToolkit for linearizing PDFs for LLM datasets/training项目地址: https://gitcode.com/GitHub_Trending/ol/olmocr本文围绕 olmOCR 仓库中的 docs/source/CHANGELOG.md 展开系统解读这份变更日志所承载的版本演进信息并深入仓库源码梳理从版本号定义、CHANGELOG 维护到 git tag 与 GitHub Release 的全自动发布链路。读完本文你将掌握 olmOCR 自 2025 年 2 月至今的完整版本时间线、各重大里程碑背后的功能演进以及复现其发布流程所需的全部脚本与操作步骤。一、CHANGELOG 是什么一份遵循双规范的版本档案olmOCR 的 CHANGELOG 文件在仓库中以双份形式存在根目录的 CHANGELOG.md 与文档站点使用的 docs/source/CHANGELOG.md两者内容保持一致均为项目的官方变更日志。文件开头明确声明了它所遵循的两项行业规范Keep a Changelog 格式所有值得记录的变更都按版本分组、按时间倒序排列顶部保留## Unreleased区块用于存放尚未发布的新改动。Semantic Versioning语义化版本版本号遵循MAJOR.MINOR.PATCH三段式语义由 pyproject.toml 中dynamic [version]配置动态读取。从内容形态看这份 CHANGELOG 更像一份版本索引档案绝大多数条目只记录版本号 发布日期两要素如## [v0.4.27] - 2026-03-12而具体的功能明细被安排在 GitHub Release 页面。这一点从仓库的发布工具链可以得到印证scripts/release_notes.py 专门从 CHANGELOG.md 中抽取指定 TAG 的条目、重组为 GitHub Release Notes 的 Whats new 与 Commits 段落说明 CHANGELOG 是自动化发布体系的事实数据源。二、版本时间线从 0.1.x 到 0.4.x 的演进全景将 CHANGELOG 中记录的版本号与日期整理成时间线可以清晰看到 olmOCR 的发布节奏——版本号密度从早期的密集迭代逐步过渡到 0.4.x 时代的稳定节奏版本阶段时间跨度代表版本v0.1.x早期迭代2025-02 至 2025-06v0.1.53 → v0.1.76v0.2.x训练体系重构2025-07 至 2025-08v0.2.0 → v0.2.3v0.3.x模型与旋转修复2025-08 至 2025-10v0.3.0 → v0.3.9v0.4.x合成数据与 RL2025-10 至 2026-03v0.4.0 → v0.4.27最新当前仓库处于v0.4.27根目录 olmocr/version.py 中_MAJOR 0、_MINOR 4、_PATCH 27与 CHANGELOG 顶部最新条目完全对应而_PATCH注释还标注了一条工程约定——主干分支上的 patch 号应比上一次发布领先一位以便为 nightly 构建预留版本空间。值得注意的是时间线上的两个版本号跳跃v0.1.53之后直接跳到v0.1.582025-02-15v0.4.7之后跳到v0.4.92025-12-01 与 2025-12-09。这种跳跃在语义化版本实践中通常意味着被跳过的编号对应的发布在构建或校验环节失败后未对外保留标签或属于内部构建。CHANGELOG 忠实记录了最终对外保留的版本序列这一点也符合 scripts/release.sh 中失败发布需删除 tag 后重发的流程设计。三、重大版本里程碑解读版本号背后的功能演进CHANGELOG 中大多数条目为精简的版本占位但结合 README.md 的 News 栏目与 CHANGELOG 中极少数携带说明的条目可以还原出各重大版本的核心内涵1. v0.1.532025-02-14最早可查的版本条目这是 CHANGELOG 中记录的最早版本也是唯一带文字说明的早期条目Fixed git checks修复 git 检查Added gemini and claude runners and a viewer新增 Gemini 与 Claude 推理 runner以及文档查看器对应的 runner 实现在仓库中均有落地olmocr/bench/runners/run_gemini.py 与 olmocr/bench/runners/run_claude.pyviewer 则对应 olmocr/viewer/dolmaviewer.py 及其 HTML 模板用于浏览由 PDF 转换生成的 Dolma 文档。2. v0.1.582025-02-15初始公开发布紧随其后的 v0.1.58 是项目的首次公开亮相与 Demo 上线README News 明确标注 Initial public launch and demo。3. v0.1.602025-03-17采样策略优化本次版本带来性能改进核心在于采样温度选择的优化。这一工程细节在 olmocr/pipeline.py 中可见端倪TEMPERATURE_BY_ATTEMPT [0.1, 0.1, 0.2, 0.3, 0.5, 0.8, 0.9, 1.0]—— 每次重试尝试会逐步升高解码温度以帮助模型克服重复输出问题这正是 v0.1.60 所宣称的性能提升的底层机制。4. v0.1.682025-05-19olmOCR-Bench 基准发布发布 olmOCR-Bench 评测基准同时因提示词 bug 修复带来 pipeline 2 分的性能提升。基准套件位于 olmocr/bench覆盖 7000 测试用例、1400 文档README 中记录了当时 77.4 的基准得分。5. v0.1.702025-05-23官方 Docker 支持发布官方 Docker 镜像仓库内对应 Dockerfile 与 Dockerfile.with-model 两份构建配置后者内置约 30GB 模型权重。6. v0.1.752025-06-17推理引擎切换这是架构层面的关键变更从 sglang 切换到 vllm 推理管线并将 Docker 镜像升级至 CUDA 12.8。pyproject.toml 的gpu可选依赖中vllm0.11.2的固定版本约束正是这次切换的延续。7. v0.2.02025-07-23训练代码重构发布全新整理过的训练器代码显著降低自行训练 olmOCR 模型的门槛对应 olmocr/train 目录中的 train.pyQwen2.5-VL SFT 微调与 grpo_train.pyGRPO RL 训练器。8. v0.3.02025-08-13自动旋转检测与幻觉修复新模型发布核心修复两项能力自动旋转检测auto-rotation detection与空白文档上的幻觉问题。旋转相关的训练配置在 olmocr/train/configs/v0.3.0 中成系列出现rotation_1epoch / rotation_2epoch / rotation_augment 等可见旋转增强是该版本训练数据策略的重点。9. v0.4.02025-10-22合成数据 强化学习v0.4.0 是 0.4.x 时代的起点引入合成数据与 RL强化学习训练使 olmOCR-Bench 得分提升约 4 分。合成数据生成逻辑位于 olmocr/synth/mine_html_templates.pyRL 训练器即 olmocr/train/grpo_train.py仓库中还附带技术报告 olmOCR-2-Unit-Test-Rewards-for-Document-OCR.pdf说明 RL 阶段采用单元测试奖励机制。10. v0.4.9 ~ v0.4.27稳定迭代期2025 年 12 月至 2026 年 3 月间版本围绕推理稳定、依赖升级与缺陷修复持续迭代v0.4.27 是当前最新版本2026-03-12。四、版本号从哪来version.py 与动态版本注入olmOCR 的版本号只有一个事实来源olmocr/version.py其结构为_MAJOR 0 _MINOR 4 # On main and in a nightly release the patch should be one ahead of the last # released build. _PATCH 27 # This is mainly for nightly builds which have the suffix .dev$DATE. See # https://semver.org/#is-v123-a-semantic-version for the semantics. _SUFFIX VERSION_SHORT {0}.{1}.format(_MAJOR, _MINOR) VERSION {0}.{1}.{2}{3}.format(_MAJOR, _MINOR, _PATCH, _SUFFIX)要点解读三段式拼接VERSION MAJOR.MINOR.PATCH SUFFIX产出如0.4.27。nightly 支持_SUFFIX主要为夜间构建预留格式为.dev$DATE例如0.4.27.dev20260312符合语义化版本对预发布版本号的规定。patch 前置约定主干分支上的_PATCH应比上一个已发布版本领先一位保证随时可以出 nightly 而不与正式版冲突。该版本号通过 pyproject.toml 的[tool.setuptools.dynamic] version {attr olmocr.version.VERSION}注入 Python 包元数据并被 olmocr/pipeline.py 以from olmocr.version import VERSION的形式引用例如用于打点日志与统计形成一处定义、处处生效的单一事实源。五、发布流程解剖从版本号到 GitHub Release 的自动化链路CHANGELOG 中的每一条版本记录背后都有一条完整的自动化发布链路。仓库的 RELEASE_PROCESS.md 给出了人工操作的完整步骤而 scripts/release.sh、scripts/prepare_changelog.py 与 scripts/release_notes.py 则构成工具链主体。1. 人工准备RELEASE_PROCESS.md更新 olmocr/version.py 中的版本号运行发布脚本./scripts/release.sh脚本负责提交 CHANGELOG 与 version.py 的变更并创建 git tagtag 的创建会触发 GitHub Actions 工作流由工作流接管剩余发布动作构建、上传等。若发布失败需要修复后重发则须先删除远程 tag 与 Release再在本地执行git tag -l | xargs git tag -d git fetch -t清理本地残留然后重复上述步骤。2. release.sh版本一致性校验与提交scripts/release.sh 的核心逻辑通过正则从olmocr/version.py提取_MAJOR、_MINOR、_PATCH、_SUFFIX并拼出VERSION_PY用python -c from olmocr.version import VERSION; print(v VERSION)获取包内报告的版本TAG两者不一致时交互式询问是否继续提示先执行pip install -e .同步版本确认后依次执行python scripts/prepare_changelog.py→git add CHANGELOG.md→ commit消息固定为Bump version to $TAG for release→ push → 创建 tag →git push --tags。脚本使用set -e严格失败退出任何一步出错都会中断流程。3. prepare_changelog.py自动写入版本条目scripts/prepare_changelog.py 负责维护 CHANGELOG.md扫描文件找到## Unreleased区块在 Unreleased 之后、最旧版本之前插入形如## [v0.4.27](https://github.com/allenai/olmocr/releases/tag/v0.4.27) - 2026-03-12的新条目日期取自当前时间若对应版本条目已存在则直接提示 CHANGELOG already up-to-date 并退出保证幂等性找不到 Unreleased 区块时抛出RuntimeError终止发布。这正是 CHANGELOG 中每个版本条目的生成源头——解释了为何每条都遵循完全一致的版本号 链接 日期格式。4. release_notes.py生成 GitHub Release Notesscripts/release_notes.py 将 CHANGELOG 转换为最终对外发布的 Release Notes读取环境变量TAG解析 CHANGELOG.md 中对应版本段将### Added / Changed / Fixed / Removed小节映射为带 emoji 的标题/⚠️/✅/生成## Whats new段落通过git log {last_tag}..{TAG} --oneline --first-parent拉取两版本间的首父提交历史生成## Commits段落跳过## Unreleased区块确保只发布已定型内容。六、从 CHANGELOG 看工程实践给读者的三个启示版本即产品档案olmOCR 用CHANGELOG 索引 GitHub Release 明细的双层结构管理变更信息版本条目的统一格式由 scripts/prepare_changelog.py 自动化保证避免了人工维护的格式漂移。版本号单一事实源所有版本信息收敛于 olmocr/version.py并由 release 脚本做双重校验杜绝包版本与 tag 不一致这类发布事故。可追溯的演进脉络通过对照 CHANGELOG 时间线与 README.md 的 News、olmocr/train/configs 下 v0.2.0 / v0.3.0 / v0.4.0 / v0.5.0 的配置目录演进读者可以完整还原基准发布 → Docker 支持 → 引擎切换 → 训练重构 → 旋转修复 → 合成数据与 RL的技术发展主线v0.5.0 配置目录已出现在 olmocr/train/configs/v0.5.0预示着下一阶段围绕 GRPO 与多模型Qwen3-VL 等的迭代方向。对于希望深入理解或复刻这套发布体系的开发者建议按如下顺序阅读仓库先通读 CHANGELOG.md 建立版本全局观再对照 RELEASE_PROCESS.md 与 scripts/release.sh 理解自动化链路最后结合 olmocr/version.py 与 pyproject.toml 掌握版本号的生成与注入机制——这份 CHANGELOG 不仅是变更记录更是理解整个项目工程化水平的入口。【免费下载链接】olmocrToolkit for linearizing PDFs for LLM datasets/training项目地址: https://gitcode.com/GitHub_Trending/ol/olmocr创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考