Revert "Add Ghostscript 10.07.1 configuration and update bundle release"

[jwaisner]

Reverts #21

[qodo-code-review]

PR Summary by Qodo

Revert Ghostscript 10.07.1 bundle configuration

⚙️ Configuration changes 🕐 Less than 10 minutes

AI Description

• Revert the previously added Ghostscript 10.07.1 bundle configuration and helper script.
• Restore the bundle release version in build metadata to the prior value.

Diagram

graph TD
  A["Build/Packager"] --> B["build.properties"] --> C["bundle.release"]
  A --> D["Ghostscript bundle"] --> E["bin/ghostscript10.07.1/"]
  E --> F["bearsampp.conf + cidfmap script"]

  subgraph Legend
    direction LR
    _proc[Process] ~~~ _file["Config/File"] ~~~ _dir["Directory"]
  end

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Keep 10.07.1 assets but gate via build flag

• ➕ Allows quick re-enable without reintroducing files via another PR
• ➕ Supports testing multiple Ghostscript versions from the same branch
• ➖ Adds conditional complexity to packaging
• ➖ Still carries unused binary/config footprint in the repo

2. Revert release metadata only (leave assets in place)

• ➕ Minimizes churn if the revert is only about versioning
• ➕ Avoids repeated add/remove of large payload directories
• ➖ Leaves potentially incorrect/unsupported assets in the bundle tree
• ➖ Creates ambiguity about the intended supported Ghostscript version

Recommendation: If the intent is a true rollback of the Ghostscript 10.07.1 introduction, the current approach (removing the versioned directory and restoring bundle.release) is the cleanest and least ambiguous. Consider the build-flag approach only if frequent version toggling is expected in the near term.

Files changed (1) +1 / -1

Other (1) +1 / -1

build.propertiesRoll back Ghostscript bundle release version +1/-1

Roll back Ghostscript bundle release version

• Reverts bundle.release from 2026.5.31 back to 2026.4.12 to match the pre-10.07.1 bundle metadata.

build.properties

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (1) 📘 Rule violations (0) 📜 Skill insights (0)

1. Release metadata mismatch 🐞 Bug ≡ Correctness

Description

build.properties now sets bundle.release to 2026.4.12, but releases.properties still maps
Ghostscript 10.07.1 to a 2026.5.31-tagged artifact. Since build.gradle uses bundle.release
(bundleRelease) in output archive naming while also using releases.properties as a download source,
rebuilding 10.07.1 will produce an archive whose release tag/path doesn’t match the advertised
mapping.

Code

build.properties[2]

+bundle.release = 2026.4.12

Evidence

The repo now reports bundle.release=2026.4.12, but still advertises a 10.07.1 artifact under the
2026.5.31 release tag; meanwhile the Gradle build uses bundle.release in the generated archive
name/path and uses releases.properties as the authoritative download mapping for versions not found
locally—so these two sources can disagree after this revert.

build.properties[1-4]
releases.properties[1-2]
build.gradle[26-45]
build.gradle[248-272]
build.gradle[720-729]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
This revert changes the module release identifier (`bundle.release`) back to `2026.4.12`, but `releases.properties` still includes a `10.07.1` entry pointing to a `2026.5.31` GitHub release asset. The build uses `bundle.release` to name/output archives, so the repo’s advertised download mapping can diverge from what this branch would build/publish.

### Issue Context
- `build.gradle` reads `bundle.release` from `build.properties` and uses it in the output path/filename.
- `build.gradle` also uses `releases.properties` as a download source when a version is not present locally.

### Fix Focus Areas
- build.properties[1-4]
- releases.properties[1-2]
- build.gradle[26-45]
- build.gradle[248-272]
- build.gradle[720-729]

### What to change
Choose one consistent state:
1) If reverting 10.07.1 support: remove the `10.07.1` (and any `2026.5.31`) entry from `releases.properties`.
2) If keeping 10.07.1 available via `releases.properties`: revert `bundle.release` back to `2026.5.31` (and restore any other reverted release metadata as needed) so produced artifacts match the mapping.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

[qodo-code-review]

1. Release metadata mismatch 🐞 Bug ≡ Correctness

build.properties now sets bundle.release to 2026.4.12, but releases.properties still maps
Ghostscript 10.07.1 to a 2026.5.31-tagged artifact. Since build.gradle uses bundle.release
(bundleRelease) in output archive naming while also using releases.properties as a download source,
rebuilding 10.07.1 will produce an archive whose release tag/path doesn’t match the advertised
mapping.

Agent Prompt

### Issue description
This revert changes the module release identifier (`bundle.release`) back to `2026.4.12`, but `releases.properties` still includes a `10.07.1` entry pointing to a `2026.5.31` GitHub release asset. The build uses `bundle.release` to name/output archives, so the repo’s advertised download mapping can diverge from what this branch would build/publish.

### Issue Context
- `build.gradle` reads `bundle.release` from `build.properties` and uses it in the output path/filename.
- `build.gradle` also uses `releases.properties` as a download source when a version is not present locally.

### Fix Focus Areas
- build.properties[1-4]
- releases.properties[1-2]
- build.gradle[26-45]
- build.gradle[248-272]
- build.gradle[720-729]

### What to change
Choose one consistent state:
1) If reverting 10.07.1 support: remove the `10.07.1` (and any `2026.5.31`) entry from `releases.properties`.
2) If keeping 10.07.1 available via `releases.properties`: revert `bundle.release` back to `2026.5.31` (and restore any other reverted release metadata as needed) so produced artifacts match the mapping.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools