Krita 5.3.3 与 6.0.3 同步更新：升级前如何验证、隔离配置与准备回滚

2026-07-30 31 预计阅读时间: 1 分钟
来源: oschina.net AI 摘要 Original link

Disclaimer: This article is an AI-assisted summary. Read it together with the original source when precision matters. The summary may omit context, version differences, or edge cases and is not official documentation.

预计阅读时间：8 分钟

Krita 同时发布了 5.3.3 和 6.0.3，两个版本都集中处理错误修复和整体改进。对于创作者，这类维护版本通常意味着更稳定的日常使用体验；对于工作室和插件维护者，真正重要的则是如何在不干扰现有项目的前提下验证新版本，并保留明确的回退路径。

两条版本线同时维护意味着什么

5.3.3 与 6.0.3 同时出现，说明用户不必为了获得修复而立刻跨越主版本。仍在使用 Krita 5 的生产环境可以评估 5.3.3，而已经迁移到 Krita 6 的用户则可以采用 6.0.3。

这两次发布都包含多项错误修复和全面改进，但现有摘要没有列出每一项修复，因此不能仅凭“维护版本”三个字推断某个具体问题已经解决。升级决策仍应围绕自己的工作流展开，例如：

  • 常用的 KRA 文档能否正常打开、保存并重新载入；
  • 数位板压感、快捷键和多显示器布局是否保持一致；
  • Python 插件、资源包、笔刷预设和色彩管理配置是否兼容；
  • 大尺寸画布、动画时间线和批量导出是否稳定；
  • 团队成员能否使用同一主版本交换文件。

主版本迁移尤其需要谨慎。不要把“6.0.3 修复很多问题”等同于“5.x 的全部插件和配置可以无条件迁移”。文件格式、插件 API 或默认行为是否发生变化，应以实际测试和完整发布说明为准。

Android 版新增应用内支持入口

Android 上的 Krita 5.3.3 允许用户直接通过应用支持项目开发，这项能力由 Google Play 商店提供。它有清晰的运行边界：设备必须具备 Google 服务，而且安装的是适用的正式版本。

以下环境不会使用 Play 商店内的支持功能：

  • 没有 Google 服务的 Android 设备；
  • Krita debug 构建；
  • Krita nightly 构建。

在这些情况下，应用会改为显示捐赠链接。对测试人员而言，这不是功能故障，而是由安装来源和运行环境决定的预期差异。企业设备、去 Google 化系统以及自建 APK 分发环境在验收时，应把这一点写进测试用例，避免把渠道限制误报成回归问题。

还需要区分“支持开发”与“购买软件功能”。现有摘要只说明新增了支持开发的入口，并未表明绘画或编辑能力会因是否支持而改变。

可以这样实践：隔离验证 Linux AppImage

下面是一套可复制的验证方法，假设你已经分别下载了 Krita 5.3.3 和 6.0.3 的 AppImage，并把文件放在当前目录。请根据实际文件名修改 KRITA5 和 KRITA6。这种方式使用独立的 XDG 目录，避免测试配置覆盖日常环境。

#!/usr/bin/env bash
set -euo pipefail

KRITA5="./krita-5.3.3-x86_64.appimage"
KRITA6="./krita-6.0.3-x86_64.appimage"
TEST_ROOT="${HOME}/krita-release-test"

for app in "$KRITA5" "$KRITA6"; do
  test -f "$app" || {
    printf 'Missing file: %s\n' "$app" >&2
    exit 1
  }
  chmod +x "$app"
done

mkdir -p \
  "$TEST_ROOT/5/config" "$TEST_ROOT/5/data" "$TEST_ROOT/5/cache" \
  "$TEST_ROOT/6/config" "$TEST_ROOT/6/data" "$TEST_ROOT/6/cache"

printf 'Downloaded file checksums:\n'
sha256sum "$KRITA5" "$KRITA6"

printf '\nLaunching Krita 5.3.3 with isolated settings...\n'
XDG_CONFIG_HOME="$TEST_ROOT/5/config" \
XDG_DATA_HOME="$TEST_ROOT/5/data" \
XDG_CACHE_HOME="$TEST_ROOT/5/cache" \
"$KRITA5" &

printf 'Launching Krita 6.0.3 with isolated settings...\n'
XDG_CONFIG_HOME="$TEST_ROOT/6/config" \
XDG_DATA_HOME="$TEST_ROOT/6/data" \
XDG_CACHE_HOME="$TEST_ROOT/6/cache" \
"$KRITA6" &

wait

脚本打印的是本地文件哈希。正式部署前，应将结果与发布方提供的校验值进行比对；不要把“成功算出哈希”误认为文件已经通过真实性验证。

测试时建议复制一份代表性项目，而不是直接操作唯一的生产文件：

mkdir -p "$HOME/krita-release-test/documents"
cp "/path/to/sample-project.kra" \
  "$HOME/krita-release-test/documents/sample-project-test.kra"

将 /path/to/sample-project.kra 替换为实际测试文档。分别用两个版本打开副本，执行绘制、保存、关闭、重新打开和导出，再检查图层、文字、动画帧、色彩和外部资源。若要比较导出结果，可以继续计算哈希：

sha256sum "$HOME/krita-release-test/exports/5/output.png" \
          "$HOME/krita-release-test/exports/6/output.png"

哈希不同不必然代表错误，因为渲染结果或文件元数据可能发生合理变化；它只是在提醒你继续做像素级或人工检查。

升级时保留一条清晰的退路

个人用户可以先备份配置和关键 KRA 文件，再升级对应主版本。工作室更适合让少量设备完成试运行，验证插件、数位板、字体、色彩配置和导出流程后，再扩大部署范围。

采用前可以检查以下事项：

  • 当前项目继续使用 5.x，还是已经明确迁移到 6.x；
  • 安装包来源与校验值是否可信；
  • 配置、资源和项目文件是否已有可恢复备份；
  • 关键插件是否声明支持目标主版本；
  • 是否用真实项目副本完成保存和导出测试；
  • Android 测试设备是否具备 Google 服务，安装包是否为正式渠道构建；
  • 出现回归时，是否能够恢复旧版本及其独立配置。

这次更新的价值不只在版本号本身。双版本维护给了用户选择空间，而 Android 端的新入口让符合条件的用户可以更直接地支持开发。稳妥的采用方式，是在自己真正依赖的画布、插件和设备上完成验证，再决定何时把新版本带入生产环境。

# Go # 全栈 # 后端 # 开源 # 开源中国

相关推荐