Drop trailing .0 in CE/PE package download links for GA releases

[ViacheslavKlimov]

Summary

For a GA release (X.Y.0), dist artifact filenames and the CE GitHub release tag drop the trailing .0 (e.g. thingsboard-4.4.deb, tag v4.4, 4.4pe), while Docker image tags and the pom/Maven version keep the full X.Y.0. Package download links and Docker tags were both derived from CE_FULL_VER, so at a GA the download links would resolve to thingsboard-4.4.0.deb and 404 against the dropped-.0 artifacts.

Changes

• src/data/versions.ts — add CE_PKG_VER, derived from CE_FULL_VER, which strips the trailing .0 for a GA (4.4.0 → 4.4) and is unchanged for patches. Re-derive PE_PKG_VER the same way (4.4.0 → 4.4pe), replacing the previous PE_FULL_VER.toLowerCase().
• Ubuntu / RHEL / Raspberry Pi install guides — CE .deb / .rpm download and install commands now use CE_PKG_VER. Docker image tags and the Maven/pip version (TB_VER) continue to use the full CE_FULL_VER.

Patches (X.Y.Z, Z>0) and GA hotfixes (X.Y.0.P) are unaffected — the derived constants equal the full version for them, so the current 4.3.1.3 release renders byte-identically.

[ViacheslavKlimov]

Review summary

Reviewed 4 changed files in Drop trailing .0 in CE/PE package download links for GA releases. Left 2 comment(s) inline.

The core change is sound. artifactVersion() strips the trailing .0 only for an exact X.Y.0 GA — patches like 4.3.1.3 and GA hotfixes like 4.4.0.1 correctly fall through unchanged — and at the current 4.3.1.3 release both CE_PKG_VER and PE_PKG_VER render byte-identically to before, as the description claims. The install-guide edits and the 'Docker/Maven keep the full version' split are consistent with the existing upgrade-steps components, which already drop the .0 via their own displayVersion field. The findings below are maintainability/consistency observations rather than correctness issues.

Additional findings

These observations are about existing code outside the PR's diff — spotted while reading surrounding context.

• src/content/_includes/docs/user-guide/integrations/remote.mdx:11 — This file still re-derives its own package suffix with export const PE_VER = PE_FULL_VER.toLowerCase(); and builds dist download URLs from it (dist.thingsboard.io/tb-http-integration-${PE_VER}.deb, .rpm, etc.). That is exactly the derivation this PR is standardizing into PE_PKG_VER. Left as-is, these remote-integration package URLs will still carry the trailing .0 at a GA while the main install guides drop it. Consider importing PE_PKG_VER here too so the 'one derivation for all package URLs' goal actually holds site-wide.
• src/content/_includes/docs/installation/ubuntu.mdx:185 and src/content/_includes/docs/installation/rhel.mdx:182 — The install step prose still interpolates the full CE_FULL_VER / PE_FULL_VER ('Download and install the ThingsBoard CE {CE_FULL_VER} package'). At a GA this sentence renders 'CE 4.4.0 package' directly above a wget … thingsboard-4.4.deb command, so the version in the text and the filename diverge. If that is intended (prose = product version, filename = artifact name) it is fine — just flagging the mismatch in case the prose should also use the short form.
• src/models/upgrade-instructions.ts — The 'drop trailing .0' rule now lives in two independent places: the new artifactVersion() regex and the hand-maintained displayVersion field that LinuxUpgradeSteps.astro / WindowsUpgradeSteps.astro use to build their download URLs. They can drift. displayVersion also doubles as a heading label so full unification is not trivial, but longer term those upgrade-step URLs could source their short form from the same helper so the rule is defined once.

---

This review was auto-generated. Findings may contain errors — please verify before applying changes.

[ViacheslavKlimov]

Two small things here. First, artifactVersion(CE_FULL_VER) is recomputed on this line even though CE_PKG_VER (declared just above) already holds exactly that value. Reusing it is a touch cleaner and expresses the real relationship (PE package name = CE package name + a pe suffix):

export const PE_PKG_VER = `${CE_PKG_VER}pe`;

Second, deriving from CE_FULL_VER rather than PE_FULL_VER means PE_PKG_VER now silently ignores PE_FULL_VER — it works only because PE's numeric base always equals CE's. The JSDoc documents this well, but the code still reads as if it depends on PE_FULL_VER when it doesn't. Would a single shared numeric-base constant feeding all four of CE_FULL_VER / PE_FULL_VER / CE_PKG_VER / PE_PKG_VER make that invariant explicit, rather than hiding it behind a cross-edition reference?

[ViacheslavKlimov]

Small naming nit: the helper is artifactVersion but the constants it feeds are *_PKG_VER, and the JSDoc has to reconcile the two as 'Artifact/package version'. Renaming the helper to pkgVersion (or the constants to *_ARTIFACT_VER) would make the helper→constant relationship read at a glance without the doc bridging the vocabulary. Non-blocking.