Version: [5284] LiDAR Relief Visualization 2.2.1

Version 2.2.1:
**Fixed**
- Replaced 19 unscoped Qt and QGIS enum references with their
Qt6-compatible
scoped forms while preserving compatibility with QGIS 3 and PyQt5.
- Added automated source and release guards so legacy enum forms are
rejected
before future plugin versions are uploaded to plugins.qgis.org.

Version 2.2.0:
**Added**
- Native contextual help for every processing parameter, including
practical
guidance on units, scale, performance, and safe starting values.
- An optional, dismissible contextual-help introduction that can be
reopened
from the LiDAR Relief plugin menu and remembers its startup
preference.
- A complete LiDAR Relief menu with native shortcuts to the Processing
toolbox,
Contact Sheet, Batch Relief, recipe import, the user guide, contextual
help,
recent recipes, and recent output folders.
- DEM preflight reporting for CRS, resolution, dimensions, extent,
sampled
elevation and nodata statistics, memory guidance, terrain-form
presets, and
metric feature-scale starting radii.
- Copy-friendly optional-dependency diagnostics covering GPU, CSF,
PDAL, ONNX,
COG, reports, temporal comparison, fusion, and labelled contact
sheets.
- One-click handoff from DEM preflight to the recommended Batch Relief
preset,
favorite tools and recipes, and non-destructive recent-item
management.
- Optional Batch Relief output naming templates and reusable recipes
containing
the successfully resolved run settings.
- Synchronized two-raster comparison, structured GeoJSON or CSV
interpretation
notes, and CRS-aware named study-area bookmarks.
- Redacted support ZIP creation containing diagnostics and optional
active-DEM
preflight information.
- Advanced e4MSTP controls for openness, Local Dominance, MSTP scales,
and tile
size, with defaults matching the previous canonical implementation.
- Regenerated the documentation's synthetic TRI figure directly from
the
current core algorithm, embedded provenance metadata, committed its
deterministic generator, and added checks for every local
documentation
image reference.
- Added an actual-QGIS screenshot and detailed first-run procedure for
every
Processing feature, illustrated guides for the plugin-menu workflows,
a
reproducible QGIS screenshot capture script and provenance manifest,
and a
version-controlled GitHub Wiki landing page.
**Changed**
- Contextual-help onboarding now appears once by default instead of at
every
QGIS startup; repeated startup display remains an explicit preference.
- Updated the optional ML/image stack to Pillow 12.3.0, ONNX 1.22.0,
and the
Python-3.10-compatible ONNX Runtime 1.23.2, with generated test models
pinned
to ONNX opset 23 for QGIS 3.34 compatibility.
**Fixed**
- Corrected CI dependency quoting, kept documentation provenance
checks free of
optional Pillow imports, and configured the direct-dependency audit to
avoid
resolving intentionally independent QGIS package pins.
**Security**
- Added a pinned direct-dependency audit inventory and automated
Semgrep and
pip-audit checks for pull requests, pushes, manual runs, and a weekly
schedule.
- Documented GDAL as a QGIS-managed dependency so its Python bindings
are not
independently upgraded beyond the version bundled with QGIS.

Version 2.1.2:
Ships the v2.1.1 work, which never reached plugins.qgis.org. No code
changes
beyond release tooling.
**Fixed**
- **A single percent sign in the changelog was silently breaking every
upload.** `qgis-plugin-ci` injects CHANGELOG.md into `metadata.txt`'s
`changelog=` field at release time, and the QGIS plugin registry
parses that
file with configparser's `BasicInterpolation`, which treats the
percent sign
as a control character. One that is not doubled, or followed by an
opening
parenthesis, makes the entire `metadata.txt` unparseable — so the
registry
refused the package. Because `qgis-plugin-ci` calls
`raise_for_status()`
without ever reading `response.text`, the only symptom was a bare
`HTTP 400` with no reason given. v2.1.1 failed three times over the
phrase
"an 84 percent reduction".
Every percent sign is now gone from CHANGELOG.md, and
`scripts/check_changelog.py` rejects undoubled ones with an
explanation, so
`./test.sh` and the release workflow both catch this before it reaches
the
registry. A test additionally proves the real changelog survives
interpolation, using the same parser the registry uses.
Older entries carried the same character for months without incident,
only
because they sit below the slice of changelog that `qgis-plugin-ci`
injects.
The trap was always armed, just out of reach.
**Added**
- **Releases now verify they actually reached QGIS users.** A
"successful"
release job has not been a reliable signal: the v2.1.0 run reported
success
and logged *"Plugin uploaded on plugins.qgis.org"*, yet the public
repository
carried on serving 2.0.22 — the version was accepted but never
approved, so
it never became installable, and nothing said so. The v2.1.1 upload
was then
refused with a bare HTTP 400 whose response body `qgis-plugin-ci`
discards.
Both states were invisible from the workflow.
`scripts/verify_published.py` now queries the public plugin repository
after
every release and reports whether the released version is genuinely
being
served, writing a warning annotation and a run summary. It is advisory
rather than fatal, because approval is a human queue on the QGIS side
and a
red tick for normal moderation latency would just train everyone to
ignore
it. It runs even when the upload step fails, since that is precisely
when
the current published state is worth knowing. A network failure
reports
"unknown", never "published".

yes

Token

2026-07-28T05:18:50.851542+00:00

3.0.0

4.99.0

None

no

Version management

Plugin details