企业官网建设流程全解析

ANTLR 4 版本发布全流程指南：从 git 分支管理到多语言运行时部署

【免费下载链接】antlr4ANTLR (ANother Tool for Language Recognition) is a powerful parser generator for reading, processing, executing, or translating structured text or binary files.项目地址: https://gitcode.com/gh_mirrors/an/antlr4

导读

本文是面向 ANTLR 4 维护者与贡献者的完整版本发布操作手册，以仓库 doc/releasing-antlr.md 为骨架，结合仓库内的发布脚本（scripts/update_antlr_version.py、scripts/deploy_to_website.py）与各运行时模块的版本管理实现，系统梳理从合并 dev 分支、递增版本号、构建 XPath 解析器、Maven 快照与正式发布，到 JavaScript / C# / Python / C++ / Dart 多目标运行时分发，再到官网 Javadoc 与 jar 更新的完整闭环。读完本文，你可以掌握 ANTLR 4 每次发版（如 4.13.1 → 4.13.2）涉及的每一处手工与自动化步骤，并理解其背后的版本一致性约束与发布约定。

1. 发版前的 Git 分支操作

1.1 将 dev 合并进 master

ANTLR 4 采用master与dev双分支开发模型，日常功能开发与修复落在dev，正式发版则基于master。发版的第一步是确保master包含全部待发布代码，可以在本地直接合并：

cd ~/antlr/code/antlr4 git checkout master git merge dev

也可以走 Pull Request 流程完成同样的合并。发版结束后（见文末"获取新鲜 dev 分支"一节），dev需要重新与master同步，保证下一个开发周期的起点与已发布版本一致。

1.2 启用 DCO 强制校验

自 4.10.1 起，ANTLR 4 采用 Linux 内核风格的DCO（Developer Certificate of Origin）取代此前需要签署文件的贡献者许可协议（CLA）。新机制下，贡献者在提交与 Pull Request 关联的每个 commit 时必须附加-s参数（即git commit -s），由 GitHub App 的 DCO 应用自动校验。

发版前务必确认antlr4仓库已开启该功能，未签 DCO 的提交将无法通过 Pull Request 检查。仓库根目录的 developer-cert-of-origin.txt 记录了 DCO 的原始文本，historical-contributors-agreement.txt 则是历史 CLA 存档。

1.3 删除可能存在的旧版本 tag

Maven Release 插件在发布时会自动为仓库创建版本 tag，若同名 tag 已存在会直接报错失败。因此发版前需要清理旧 tag（以下以 4.13.2 为例）：

git tag -d 4.13.2 git push origin :refs/tags/4.13.2 git push upstream :refs/tags/4.13.2

其中origin与upstream分别对应 fork 与官方仓库远端，需要两个远端都删除干净。

1.4 Go runtime 的 release tag（历史说明）

Go 模块要求发布 tag 带v前缀。文档中记录了早期做法：为 Go runtime 子模块单独打一个带v的 tag：

git tag -a runtime/Go/antlr/v4/v4.13.2 -m "Go runtime module only" git push upstream runtime/Go/antlr/v4/v4.13.2 git push origin runtime/Go/antlr/v4/v4.13.2

不过该小节在文档中已注明"此步骤可能不再必要"——Go runtime 已迁移到独立的 runtime/Go 目录对应的独立发布仓库维护，v4.13.2这类带v的 tag 由 Go 侧仓库自行管理，ANTLR 主仓库不再需要"双 tag"。

2. 递增版本号：代码与各配置文件

ANTLR 4 的版本号散落在多个运行时与构建文件中，发版时需要同步更新。仓库为此提供了半自动脚本 scripts/update_antlr_version.py，用法为传入新旧两个版本号：

python scripts/update_antlr_version.py 4.13.1 4.13.2

脚本运行过程会依次：

1. 打印Updating ANTLR version from 4.13.1 to 4.13.2；
2. 询问是否执行mvn clean并清理各运行时构建目录（C# 的bin/obj、C++ 的build、JavaScript 的dist等）；
3. 读取 scripts/files-to-update.txt 中列出的文件清单，逐个做字符串替换；
4. 对替换结果打印两类告警：{旧版本} not in {文件}（该文件未含旧版本号）或{旧版本} appears on N lines so _not_ updating {文件}（同一文件中旧版本出现多次、脚本出于安全跳过）。

2.1 版本号文件清单

files-to-update.txt采用"每行一个文件"的格式，行首带*表示该文件允许多处替换。当前清单覆盖以下关键位置：

脚本结尾还会打印两条需要人工处理的提示：

• runtime/Cpp/runtime/src/Version.h采用非标准版本机制，需要手动编辑。从源码可见其不是简单字符串，而是拆分为ANTLRCPP_VERSION_MAJOR/ANTLRCPP_VERSION_MINOR/ANTLRCPP_VERSION_PATCH三个宏，并通过ANTLRCPP_MAKE_VERSION合成数值版本号与字符串版本号（见 runtime/Cpp/runtime/src/Version.h）；
• 部分目标无法接受4.x这种两位版本号，必须写成4.x.0：包括runtime/Dart/pubspec.yaml与runtime/JavaScript/package.json，因为 Dart pub 与 npm 对 semver 的解析要求三位段。

2.2 Java runtime 版本常量的特殊要求

Java 运行时的版本常量位于 runtime/Java/src/org/antlr/v4/runtime/RuntimeMetaData.java，当前为：

public static final String VERSION = "4.13.2";

发版时该文件绝不能残留-SNAPSHOT后缀。其背后有明确的运行时语义：RuntimeMetaData的 javadoc 说明，4.3 起代码生成器会在每个生成的 lexer/parser 中硬编码"生成工具版本"常量，并引用运行时的VERSION编译期常量；checkVersion(String generatingToolVersion, String compileTimeVersion)在生成代码初始化时被调用，用于检测两类版本不匹配：

• 生成代码所用 Tool 版本与当前运行时版本不一致；
• 编译所引用运行时版本与当前执行运行时版本不一致。

检测逻辑并非要求完全相等，而是采用getMajorMinorVersion提取x.y主次版本号进行比较（见 RuntimeMetaData.java）：只要主次版本一致（例如4.13与4.13.1），就认为兼容、不告警；不一致则向 stderr 输出警告。因此发版时若 RuntimeMetaData 中的版本带有-SNAPSHOT，会污染所有依赖它做版本对齐的生成代码。

2.3 全仓库残留版本扫描

版本号替换完成后，建议再做一次全量扫描，确认没有遗漏的旧版本引用。官方推荐做法是先mvn clean再配合find/grep过滤掉构建产物与无关文件：

mvn clean find . -type f -exec grep -l '4\.12\.0' {} \; | grep -v -E '\.o|\.a|\.jar|\.dylib|node_modules/|\.class|tests/|CHANGELOG|\.zip|\.gz|.iml|\.svg'

排除项覆盖二进制产物（.o/.a/.jar/.dylib/.class/.zip/.gz）、第三方依赖（node_modules/）、测试代码（tests/）与 IDE/辅助文件（.iml、.svg）。也可以直接用上面提到的python scripts/update_antlr_version.py <旧> <新>重跑一遍，观察脚本输出的not in告警来确认清理干净。确认无误后提交并推送代码。

2.4 PHP runtime 的独立更新

PHP runtime 维护在独立的仓库中，本仓库只需拷贝一份用于跑单元测试，因此其版本号（RuntimeMetaData.php）需要在独立仓库手动递增并发布：

cd ~/antlr/code/antlr-php-runtime/src git checkout dev # 默认开发分支 git pull origin dev # ... 编辑 RuntimeMetaData.php 将版本号改为 4.13.2 ... git commit -a -m "Update PHP Runtime to latest version" git push origin dev git checkout master git pull origin master git merge dev git push origin master

流程同样是"dev 分支改版本 → 合入 master → 推送"，与主仓库的分支模型保持一致。

3. 构建 XPath 解析器：绕开循环依赖

ANTLR 4 的 XPath 支持（runtime/Java/src/org/antlr/v4/runtime/tree/xpath下的XPathLexer.g4、XPath.g4等）存在一个经典的循环依赖问题（issue #3600）：生成新版本 XPath 解析器需要用到新版本工具，而新版本工具自身的构建又依赖 XPath 解析器。Java 目标的解法是手工构建XPath.java，避免"用 4.13.2 生成 4.13.2 的解析器"。

对于 C++、C#、Python3 目标，则需要在发布时用新版本工具（4.13.2-SNAPSHOT）重新生成对应的 XPath 词法/语法文件：

cd runtime/Cpp/runtime/src/tree/xpath java -cp ":/Users/parrt/.m2/repository/org/antlr/antlr4/4.13.2-SNAPSHOT/antlr4-4.13.2-SNAPSHOT-complete.jar:$CLASSPATH" org.antlr.v4.Tool -Dlanguage=Cpp XPathLexer.g4 cd runtime/CSharp/src/Tree/Xpath java -cp ":/Users/parrt/.m2/repository/org/antlr/antlr4/4.13.2-SNAPSHOT/antlr4-4.13.2-SNAPSHOT-complete.jar:$CLASSPATH" org.antlr.v4.Tool -Dlanguage=CSharp XPathLexer.g4 cd runtime/Python3/tests/expr java -cp ":/Users/parrt/.m2/repository/org/antlr/antlr4/4.13.2-SNAPSHOT/antlr4-4.13.2-SNAPSHOT-complete.jar:$CLASSPATH" org.antlr.v4.Tool -Dlanguage=Python3 Expr.g4 cd runtime/Python3/src/antlr4/xpath java -cp ":/Users/parrt/.m2/repository/org/antlr/antlr4/4.13.2-SNAPSHOT/antlr4-4.13.2-SNAPSHOT-complete.jar:$CLASSPATH" org.antlr.v4.Tool -Dlanguage=Python3 XPathLexer.g4

-Dlanguage=分别指定 Cpp / CSharp / Python3 目标，-cp指向本地 Maven 仓库中新版本工具的 complete jar（antlr4-4.13.2-SNAPSHOT-complete.jar）。生成的 XPath 文件属于"生成产物"，scripts/files-to-update.txt 末尾专门以注释形式登记了XPathLexer.py、XPathLexer.cpp/.h、XPathLexer.cs等生成文件，提醒维护者它们由工具生成、不应手工改版本号。

文档同时说明：patch 版本（如 4.13.2 → 4.13.3）通常无需重跑此步骤，只有改动 ATN 序列化格式的大版本才需要重新生成 XPath 解析器。

4. Maven 仓库发布

4.1 配置 ~/.m2/settings.xml

Maven 发布需要与 Sonatype 暂存（staging）服务器通信，并在正式发布时用 GPG 对构件签名。先在~/.m2/settings.xml中配置 staging 服务器账号与签名密钥，模板如下（文件权限必须收紧为仅本人可读写）：

<?xml version="1.0" encoding="UTF-8"?> <!-- User-specific configuration for maven. Includes things that should not be distributed with the pom.xml file, such as developer identity, along with local settings, like proxy information. --> <settings> <servers> <server> <id>sonatype-nexus-staging</id> <username>sonatype-username</username> <password>XXX</password> </server> <server> <id>sonatype-nexus-snapshots</id> <username>sonatype-username</username> <password>XXX</password> </server> </servers> <profiles> <profile> <activation> <activeByDefault>false</activeByDefault> </activation> <properties> <gpg.keyname>UUU</gpg.keyname> <gpg.passphrase>XXX</gpg.passphrase> </properties> </profile> </profiles> </settings>

要点：

• sonatype-nexus-staging与sonatype-nexus-snapshots两个 server id 分别对应正式发布与快照发布的 Nexus 远端，<id>必须与根 pom.xml 中<distributionManagement>配置的 repository id 一致；
• GPG 密钥名与口令放在<profile>的<properties>中（gpg.keyname、gpg.passphrase），且该 profile 默认不激活；
• 在 Unix 上务必执行chmod 600 ~/.m2/settings.xml之类收紧权限（文档示例为-rw-------），因为文件内含密码与私钥口令。

4.2 部署 SNAPSHOT 到暂存服务器

快照版本（如4.13.2-SNAPSHOT）的目标是推送到 Sonatype 的 snapshots 仓库。两步走：

mvn install -DskipTests # 让 jar 对 maven 可见 mvn deploy -DskipTests

deploy阶段会按 reactor 顺序逐个模块上传 jar 与 pom，根 pom.xml 定义了 ANTLR 4 的 reactor 模块清单：runtime/Java（Runtime）、tool（Tool）、antlr4-maven-plugin（Maven 插件）、tool-testsuite（工具测试）、runtime-testsuite（运行时测试）。文档中的示例构建输出展示了完整的 reactor 摘要：

[INFO] ANTLR 4 ............................................ SUCCESS [ 4.073 s] [INFO] ANTLR 4 Runtime .................................... SUCCESS [ 13.828 s] [INFO] ANTLR 4 Tool ....................................... SUCCESS [ 14.032 s] [INFO] ANTLR 4 Maven plugin ............................... SUCCESS [ 6.547 s] [INFO] ANTLR 4 Runtime Test Annotations ................... SUCCESS [ 2.519 s] [INFO] ANTLR 4 Runtime Test Processors .................... SUCCESS [ 2.385 s] [INFO] ANTLR 4 Runtime Tests (4th generation) ............. SUCCESS [ 15.276 s] [INFO] ANTLR 4 Tool Tests ................................. SUCCESS [ 2.233 s] [INFO] BUILD SUCCESS

4.3 正式发布：release:prepare 与 release:perform

正式发布走 Maven Release 插件，分两步：

mvn deploy -DskipTests mvn release:prepare -Darguments="-DskipTests"

release:prepare会交互式询问每个模块的发布版本号、SCM tag 名与下一个开发版本号。以 4.13.2 为例，典型会话如下：

What is the release version for "ANTLR 4"? (org.antlr:antlr4-master) 4.13.2: : 4.13.2 What is the release version for "ANTLR 4 Runtime"? (org.antlr:antlr4-runtime) 4.13.2: : What is the release version for "ANTLR 4 Tool"? (org.antlr:antlr4) 4.13.2: : What is the release version for "ANTLR 4 Maven plugin"? (org.antlr:antlr4-maven-plugin) 4.13.2: : What is the release version for "ANTLR 4 Runtime Test Generator"? (org.antlr:antlr4-runtime-testsuite) 4.13.2: : What is the release version for "ANTLR 4 Tool Tests"? (org.antlr:antlr4-tool-testsuite) 4.13.2: : What is SCM release tag or label for "ANTLR 4"? (org.antlr:antlr4-master) antlr4-master-4.13.2: : 4.13.2 What is the new development version for "ANTLR 4"? (org.antlr:antlr4-master) 4.13.3-SNAPSHOT:

Maven 会遍历所有 pom.xml，把版本从4.13.2-SNAPSHOT改为4.13.2（发布），随后再执行：

mvn release:perform -Darguments="-DskipTests"

release:perform会把 pom 版本改回下一个开发版本（如4.13.3-SNAPSHOT，与当前仓库根 pom.xml 中的状态一致），并通过 git 推送 pom 变更与 tag。-Darguments="-DskipTests"用于在发布构建中跳过测试。

GPG 签名与 class 文件版本校验

发布涉及 GPG 签名，需要先安装 gpg 并生成、发布公钥，再在.m2/settings.xml中指向该公钥。在部分环境下 gpg 取不到 tty 会失败，需要先导出：

export GPG_TTY=$(tty)

发布构建完成后，可用od校验生成的 class 文件字节码版本。Java 11 编译产物应为0x37（十进制 55），出现在 class 文件魔数0xCAFEBABE之后：

od -h tool/target/classes/org/antlr/v4/Tool.class | head -1 0000000 feca beba 0000 3700 ed04 0207 0a9d 0100 ^^

同时确认 runtime 的 class 版本符合预期（示例输出中0x34即 Java 8 的 52）：

od -h runtime/Java/target/classes/org/antlr/v4/runtime/Token.class | head -1

根 pom.xml 当前配置maven.compiler.source/target为 11，因此发版时 Tool.class 应呈现 Java 11 的0x37字节码版本。

关闭并发布 Staging Repository

release:perform之后，构件位于 Sonatype 的暂存仓库，需要在 Sonatype 管理界面左侧进入Staging Repositories，选中本次暂存仓库执行Close（校验构件与签名），刷新后再执行Release。发布成功后构件会同步到 Maven Central 的org/antlr组下，所有历史版本可在 Central 仓库的org.antlr:antlr4-runtime路径下查看。

5. 多语言运行时分发

ANTLR 4 的各个运行时目标使用各自生态的包管理器发布，各自有独立的账号与权限要求。

5.1 JavaScript：npm

npm 包发布前需要先构建产物（npm run build），文档特别提醒npm publish时不要带上antlr4目录，否则可能意外推送旧版本：

cd runtime/JavaScript rm -rf node_modules npm update npm install npm run build npm login # 需要 npmjs.com 账号，支持 2FA npm publish

构建与发布均在 runtime/JavaScript 目录内进行，包名与版本见 runtime/JavaScript/package.json。发布后再把源码打成 zip 归档到网站下载区：

cd src zip -r ~/antlr/sites/website-antlr4/download/antlr-javascript-runtime-4.13.2.zip .

5.2 C#：NuGet

C# 目标受制于构建环境：只能从 Windows 机器发布，因为 macOS 上的 Visual Studio for Mac 只能构建 netstandard2.0 版本。前置条件为安装msbuild与nuget。

先构建 Release 版本并校验强名称签名（项目通过Antlr4.snk与<SignAssembly>true</SignAssembly>启用签名，见 runtime/CSharp/src/Antlr4.csproj）：

cd runtime/CSharp/src dotnet build -c Release Antlr4.csproj

确认bin/Release下同时存在 netstandard2.0 与 net45 两个目标（csproj 中net45;netstandard2.0仅在 Windows 上启用），并逐个校验 DLL 签名：

sn -v bin/Release/netstandard2.0/Antlr4.Runtime.Standard.dll sn -v bin/Release/net45/Antlr4.Runtime.Standard.dll

两者都应输出 "valid" 之类的有效签名提示。发布到 NuGet 有两种方式：一是登录 NuGet 网站手动上传Antlr4.Runtime.Standard.<version>.nupkg；二是在命令行用 NuGet API key 推送：

cd bin/Release nuget push Antlr4.Runtime.Standard.<version>.nupkg <your-key> -Source https://www.nuget.org/api/v2/package

需要你具有 "ANTLR 4 Standard Runtime" 包的 NuGet owner 权限。

5.3 Python：PyPI（twine）

Python 目标使用twine上传到 PyPI，面向 Python 3。首先配置~/.pypirc（同样收紧文件权限为 600）：

[distutils] # this tells distutils what package indexes you can push to index-servers = pypi pypitest [pypi] username: parrt password: xxx [pypitest] username: parrt password: xxx

然后构建并上传（sdist 与 wheel 两个产物都传）：

cd runtime/Python3 python -m build # assume you have ~/.pypirc set up twine upload dist/antlr4_python3_runtime-4.13.2.tar.gz dist/antlr4_python3_runtime-4.13.2-py3-none-any.whl

包的元数据（名称antlr4-python3-runtime、版本号、pygrun入口脚本等）定义在 runtime/Python3/pyproject.toml，源码布局为src目录（package-dir = {"" = "src"}）。

5.4 C++：四平台部署脚本

C++ 目标是最复杂的发布场景，因为需要覆盖多个平台、多种构建形态：

iOS 不做预编译库的原因是签名依赖活跃的 iOS 开发者账号，因此与 Linux 一样交给用户自行构建。仓库 runtime/Cpp 下提供了三个部署脚本：

• macOS：在装有 Xcode 7+ 的 Mac 上执行./deploy-macos.sh；
• 源码包：在任何 Linux 或 Mac 上执行./deploy-source.sh，打包源码与 cmake 构建文件；
• Windows：执行deploy-windows.cmd，脚本会检测 VS 2017 / VS 2019 是否安装，为每个找到的版本构建对应二进制，需要安装 7-Zip 并把其加入 PATH。

示例流程（Mac 上）：

cd runtime/Cpp rm CMakeCache.txt # 否则可能找不到部分 include 文件 ./deploy-macos.sh cp antlr4-cpp-runtime-macos.zip ~/antlr/sites/website-antlr4/download/antlr4-cpp-runtime-4.13.2-macos.zip

源码包流程（任意 Mac/Linux）：

cd runtime/Cpp ./deploy-source.sh cp antlr4-cpp-runtime-source.zip ~/antlr/sites/website-antlr4/download/antlr4-cpp-runtime-4.13.2-source.zip

Windows 流程：

cd runtime/Cpp deploy-windows.cmd Community cp antlr4-cpp-runtime-vs2019.zip ~/antlr/sites/website-antlr4/download/antlr4-cpp-runtime-4.13.2-vs2019.zip

最后把 zip 归档提交到网站仓库（注意先按需重命名成带具体版本号的文件名）：

pushd ~/antlr/sites/website-antlr4/download git add antlr4-cpp-runtime-4.13.2-macos.zip git add antlr4-cpp-runtime-4.13.2-windows.zip git add antlr4-cpp-runtime-4.13.2-source.zip git commit -a -m 'update C++ runtime' git push origin gh-pages popd

C++ 运行时的版本号同时存在于 runtime/Cpp/VERSION（内容为4.13.2）与 runtime/Cpp/runtime/src/Version.h 的宏定义中，后者由update_antlr_version.py提示需手工维护。

5.5 Dart：pub.dev

Dart 目标需要先安装 Dart SDK，然后直接发布到 pub.dev：

cd runtime/Dart dart pub publish

发布时 pub 会提示"新版本未找到 changelog"，输入N忽略该警告即可继续。包名与版本见 runtime/Dart/pubspec.yaml。

6. 更新官网：版本号、Javadoc 与 jar

6.1 一键脚本

官方提供了 scripts/deploy_to_website.py 完成网站版本号更新、Javadoc 解压与 jar 拷贝的自动化部分：

cd ~/antlr/code/antlr4 python scripts/deploy_to_website.py 4.13.1 4.13.2

脚本依次执行：

1. 更新网站端需要改版本的 4 个文件：download.html、index.html、api/index.html、scripts/topnav.js；
2. 从本地 Maven 仓库解压三份 javadoc jar 到网站的api/Java（来自antlr4-runtime-4.13.2-javadoc.jar）、api/JavaTool（来自antlr4-4.13.2-javadoc.jar）与api/maven-plugin/latest（来自antlr4-maven-plugin-4.13.2-javadoc.jar）；
3. 从本地 Maven 仓库拷贝antlr4-runtime-4.13.2.jar与antlr4-4.13.2-complete.jar到网站download/目录并git add。

脚本输出的"Javadoc copied / Jars copied"清单即为核对依据。注意：运行时与工具的 javadoc jar 就位于本地 Maven 仓库org/antlr组下，路径形如~/.m2/repository/org/antlr/antlr4-runtime/4.13.2/antlr4-runtime-4.13.2-javadoc.jar——这正是第 4 节 Maven 发布产物的直接复用。

6.2 手工收尾

自动化完成后仍需人工操作：

cd ~/antlr/sites/website-antlr4 git commit -a -m 'Update website, javadoc, jars to 4.13.2' git push origin gh-pages

因为deploy_to_website.py只负责文件操作，不代替维护者提交代码。

7. 发版后收尾

7.1 同步 dev 分支

正式发布合入 master 后，需要把 master 同步回 dev，让下一个开发周期从已发布状态继续：

git checkout master git pull upstream master git checkout dev git pull upstream dev git merge master git push origin dev git push upstream dev

7.2 其他发布跟进项

文档列出的发版后事项还包括：

• 使用新版本 antlr jar 重新构建 ANTLR Intellij 插件；
• 在 GitHub Releases 页面编写发布说明（release notes），列出新特性、修复与破坏性变更；
• 更新 lab.antlr.org 在线实验站点。

这些步骤通常由维护者在发版当天完成，其中发布说明是用户感知版本变更的主要入口，可结合仓库根目录的 CHANGES.txt 整理变更清单。

8. 发版清单速览

将全文压缩为一份可执行的检查清单：

1. Git：dev合入master；确认 DCO 强制校验开启；删除旧版本 tag（git tag -d+ 推空 refs 到 origin/upstream）。
2. 版本号：python scripts/update_antlr_version.py <旧> <新>更新 scripts/files-to-update.txt 中的文件；手工改 runtime/Cpp/runtime/src/Version.h；确认 RuntimeMetaData.java 无-SNAPSHOT；mvn clean+find/grep扫描残留版本；独立仓库更新 PHP runtime 版本并发布。
3. XPath 解析器：大版本（ATN 序列化变更）时用antlr4-4.13.2-SNAPSHOT-complete.jar重新生成 Cpp / CSharp / Python3 的 XPath 解析器。
4. Maven：配置~/.m2/settings.xml（staging 账号 + GPG）；mvn install -DskipTests && mvn deploy -DskipTests推快照；mvn release:prepare -Darguments="-DskipTests"与mvn release:perform；export GPG_TTY=$(tty)；用od校验 class 字节码版本；Sonatype 上 Close → Release staging repository。
5. 运行时目标：JavaScript 走 npm publish；C# 在 Windows 上dotnet build+sn -v验签 + NuGet 推送；Python 用python -m build+twine upload；C++ 用 runtime/Cpp 下三个部署脚本产出 macOS/Windows/source 三种 zip；Dart 用dart pub publish。
6. 官网：python scripts/deploy_to_website.py <旧> <新>更新版本号、解压 javadoc、拷贝 jar，然后手工 commit/push gh-pages。
7. 收尾：dev 重新同步 master；重建 Intellij 插件；写 GitHub release notes；更新 lab.antlr.org。

参考文件索引

• 发布主文档：doc/releasing-antlr.md
• 版本更新脚本：scripts/update_antlr_version.py、scripts/files-to-update.txt
• 网站部署脚本：scripts/deploy_to_website.py
• 版本常量实现：runtime/Java/src/org/antlr/v4/runtime/RuntimeMetaData.java、runtime/Swift/Sources/Antlr4/RuntimeMetaData.swift、runtime/Cpp/runtime/src/Version.h
• 构建与发布配置：pom.xml、runtime/CSharp/src/Antlr4.csproj、runtime/Python3/pyproject.toml、runtime/Dart/pubspec.yaml、runtime/JavaScript/package.json
• C++ 多平台部署：runtime/Cpp/deploy-macos.sh、runtime/Cpp/deploy-source.sh、runtime/Cpp/deploy-windows.cmd
• 贡献与发布历史：CONTRIBUTING.md、CHANGES.txt、developer-cert-of-origin.txt

【免费下载链接】antlr4ANTLR (ANother Tool for Language Recognition) is a powerful parser generator for reading, processing, executing, or translating structured text or binary files.项目地址: https://gitcode.com/gh_mirrors/an/antlr4