Django 6.1 Release Candidate 1 已经发布。这是正式版到来前集中验证新功能、可用性改进和项目兼容性的关键窗口。候选版本阶段也意味着字符串冻结，翻译人员可以据此提交稳定的本地化内容。
如果未来两周没有发现无法及时解决的重大缺陷，Django 6.1 正式版预计将在 8 月 5 日前后发布；若时间发生变化，Django 团队会在官方论坛沟通。
RC 阶段应该验证什么
RC 的价值不只是让开发者提前体验界面或 API。对实际项目而言，更重要的是把现有代码、依赖和部署流程放到新版本上运行，尽早暴露兼容性问题。
建议重点检查以下内容：
- 项目能否正常启动，系统检查是否出现新错误或警告。
- 数据库迁移的生成和执行结果是否符合预期。
- URL 路由、中间件、模板、自定义字段和管理后台是否正常工作。
- 第三方 Django 应用是否声明并实际支持 Django 6.1。
- 单元测试、集成测试以及异步任务是否仍能通过。
- 翻译字符串、日期格式和本地化页面是否存在回归。
RC 仍然是预发布版本，不应未经完整验证就替换生产环境。更稳妥的做法是在独立虚拟环境、CI 流水线或临时部署环境中测试。
建立一个隔离的 Django 6.1 RC1 验证环境
可以这样实践：创建全新的 Python 虚拟环境，从 PyPI 安装指定候选版本，再运行 Django 的系统检查。执行前请确认项目所用 Python 版本满足 Django 6.1 的要求；来源摘要没有列出具体 Python 版本范围，因此应以包元数据和 Django 6.1 文档为准。
python -m venv .venv-django61
# Linux/macOS
. .venv-django61/bin/activate
# Windows PowerShell 使用：
# .venv-django61\Scripts\Activate.ps1
python -m pip install --upgrade pip
python -m pip install "Django==6.1rc1"
python -m django --version
如果只是做最小冒烟测试，可以创建一个临时项目：
django-admin startproject rc_check
cd rc_check
python manage.py check
python manage.py migrate
python manage.py test
python manage.py runserver
对于已有项目，不要直接覆盖当前锁文件。可以复制工作目录或建立测试分支，然后安装项目依赖并单独升级 Django：
python -m pip install -r requirements.txt
python -m pip install --upgrade "Django==6.1rc1"
python manage.py check --deploy
python manage.py makemigrations --check --dry-run
python manage.py migrate --plan
python manage.py test
makemigrations --check --dry-run 用于发现升级后是否意外产生模型迁移，migrate --plan 则让团队在真正修改数据库前审查迁移计划。check --deploy 会执行面向部署的额外检查，但它不能替代真实流量下的回归测试。
把 RC 纳入 CI，而不是依赖人工试跑
如果项目当前仍需支持已发布的 Django 版本，可以增加一个允许失败的 RC 测试任务。下面是一个可改造的 GitHub Actions 示例，假设项目通过 requirements.txt 安装依赖，并可使用 python manage.py test 运行测试：
name: Django 6.1 RC compatibility
on:
workflow_dispatch:
pull_request:
push:
branches: [main]
jobs:
django-61-rc:
runs-on: ubuntu-latest
continue-on-error: true
steps:
- uses: actions/checkout@v4
- uses: actions/setup-python@v5
with:
python-version: "3.x"
cache: pip
- name: Install project and release candidate
run: |
python -m pip install --upgrade pip
python -m pip install -r requirements.txt
python -m pip install --upgrade "Django==6.1rc1"
- name: Run checks and tests
run: |
python manage.py check
python manage.py makemigrations --check --dry-run
python manage.py test
实际使用时，应把 python-version 改成项目明确支持且符合 Django 6.1 要求的版本。如果依赖文件把 Django 锁定为旧版本，安装 RC 时可能出现依赖冲突；这本身就是值得记录的升级信号。待兼容问题解决后，可以移除 continue-on-error: true，让 RC 回归直接阻止不兼容变更合并。
发现问题后，提交可复现的报告
候选版本的目标之一是发现并修复正式发布前的缺陷。报告问题时，避免只写“升级后不能运行”，应提供足够的信息让维护者复现：
Django version: 6.1rc1
Python version: <具体版本>
Database and version: <例如 PostgreSQL 具体版本>
Operating system: <系统与版本>
Steps to reproduce:
1. 创建或运行……
2. 执行……
3. 观察到……
Expected result:
<预期行为>
Actual result:
<实际行为和完整 traceback>
提交前应尽量把问题缩减到最小项目，并确认它在此前使用的 Django 版本上不会出现。缺陷应提交到 Django 的问题跟踪系统，而发布计划变化会通过 Django 论坛公布。
此次发布使用的 PGP 密钥标识为 Jacob Walls 的 131403F4D16D8DC7。如果从下载页面获取签名发布包，应在验证签名时核对完整密钥标识，并通过可信渠道确认密钥归属；仅看到匹配的短标识不足以建立完整信任链。
团队采用清单
在正式版发布前，可以完成一轮范围明确的升级演练：
- 在隔离环境中安装精确版本
Django==6.1rc1。 - 运行系统检查、迁移检查和完整测试套件。
- 检查关键第三方包的兼容性与依赖约束。
- 对登录、权限、表单、管理后台和核心业务流程做人工回归。
- 记录性能变化、弃用警告和新增迁移。
- 将可复现缺陷提交到问题跟踪系统。
- 生产环境继续使用稳定版本，等待正式版和依赖生态完成验证。
RC1 给团队提供的是一次低成本提前发现问题的机会。越接近真实项目、真实数据库和真实部署配置，测试结果就越有价值。