繁體中文

Next-gen sibling of autobump-rb — the stable, mechanical Gentoo-overlay autobump engine that ships to CI. autobump-gui is where the architecture and GUI handling are developed separately and in stages, not mixed into the stable engine. It starts as a byte-for-byte copy of autobump-rb (parity 10/10, e2e green) and adds:

• An explicit op registry — a thin dispatcher plus declarative per-package ops (escalate / payload-bump / source-bump, more to come), à la Homebrew livecheck's Strategy classes, nvchecker's source key, and NixOS passthru.updateScript. Adding a package-type handler never touches the dispatcher (cli.rb → Ops.select(ctx)).
• A GUI-package plan — GUI apps build/install cleanly but cannot be launch-verified in CI (confirmed across NixOS/openSUSE/Gentoo: every ecosystem keeps launch/smoke advisory, never an auto-merge gate). Short term: payload-bump op + non-launch structural checks (build clean + payload tree diff + soname resolution + .desktop/icon present) + an advisory headless probe. Long term (opt-in, needs KVM): VM + OCR/screenshot deep verification, openQA / NixOS-VM style — this is where a dedicated server / PVE host comes in.

Design & research: the full ops-toolbox architecture and GUI plan (synthesised from a two-round deep-research on NixOS/openSUSE/Debian/Arch/Homebrew) are in the maintainer notes' deep-research/.

ruby bin/autobump <cat/pkg> <newver> --check      # classify + pick op: mechanical (0) or escalate (3)
ruby bin/autobump <issue#> --check                # resolve an nvchecker bump issue first

bash parity/parity.sh                             # hermetic decision parity vs reference/autobump.sh (10/10)
sudo bash parity/e2e.sh                           # hermetic END-TO-END: really emerges a fixture (root+portage)
rake                                              # syntax + parity (what CI runs)

Env-driven (any overlay): AUTOBUMP_REPO, AUTOBUMP_UPSTREAM_REPO, etc. GPL-2.