# FreeDMR v1.5.0 release notes

FreeDMR v1.5.0 introduces HDStack, a multi-process deployment for the standard
container. It raises aggregate HBP capacity by distributing active hotspot and
repeater sessions across up to five FreeDMR workers while retaining the
existing 100-connection boundary for each worker.

## Before upgrading

- The standard container now chooses the number of HDStack workers from the
  available CPU count minus one, clamped to one through five. Set `HDSTACK=1`
  explicitly to retain the established single-process layout.
- Set `HDSTACK_BASEID` to the aggregator server ID. Workers use successive IDs
  beginning at `HDSTACK_BASEID + 1`.
- The read-only FreeDMR container requires a writable `/tmp`. The shipped
  Compose file provides this with `tmpfs: /tmp`; retain that setting in custom
  deployments.
- Existing deployments must update their Compose configuration to receive new
  services and mounts; pulling the FreeDMR image alone does not rewrite an
  existing `docker-compose.yml`.

## HDStack

- New HBP sessions are assigned round-robin across workers. A DMR ID remains
  pinned to its exact worker port for the active session, preserving its login,
  bridge and `OPTIONS` state.
- A no-HBP aggregator owns external FBP and OBP relationships. Workers connect
  to it over private FBP v5/FBCP links.
- Each worker has an isolated Loro playback process and private ECHO link when
  ECHO is enabled.
- The reporting MUX presents worker reports through the existing reporting
  socket. It prefixes system names with the stable worker number, for example
  `1:SYSTEM-001`, to avoid collisions.
- The optional separate `bridge.py` process is disabled by default. Set
  `HDSTACK_BRIDGE=1`, assign it a distinct server ID and configure its skeleton
  config and rules files when bridge routing is required.
- HDStack does not provide active worker failover, live migration or persistent
  session affinity. A failed worker's active sessions are not moved.

See [HDStack multi-process deployment](hdstack.md) for configuration, generated
ports, reporting and operational limitations.

## Data Gateway

New installations include the stable FreeDMR Data Gateway container. Each
worker has a direct FBP v5/FBCP relationship to the gateway for locally
originated DMR traffic. Existing installations retain the legacy D-APRS path
unless the native `DATA_GATEWAY` setting and relationship are enabled.

The installer requests the APRS-IS login and passcode and writes the matching
worker relationships. The gateway remains a separate container and is not a
fallback when its native links are unavailable.

The separately downloadable `upgrade-daprs-to-data-gateway.sh` helper can
migrate the documented legacy D-APRS Compose service while preserving and
backing up the surrounding FreeDMR configuration.

## Other operator-visible changes

- Network direct dial is available and defaults to local TG9 on TS1. Set
  `NETWORK_DIRECT_DIAL_SLOT: 0`, or session option `NDD_SLOT=0`, to disable it.
- Dial-a-TG control, defaults and timers can be configured independently for
  TS1 and TS2. Existing TS2 option aliases remain supported.
- `DIAL_A_TG` and `DYNAMIC_TG_ROUTING` can disable their respective dynamic
  routing behaviours.
- HBP `OPTIONS` input is bounded to 255 bytes. Oversized values are
  acknowledged but ignored.
- Optional DMR data observability is available through `DATA_PACKET_LOGGING`.
  It is disabled by default because decoded logs may contain message or
  location content.
- Reporting includes source server and repeater metadata without changing the
  existing leading report fields.
- The shipped `ALLOW_UNREG_ID` default is now `True` for established FreeDMR
  access compatibility.
- The installer uses the current Docker repository setup on Debian 12.

## Compatibility

FBP v5 and OBP v1 remain distinct supported peer protocols. The HDStack
internal topology uses FBP v5/FBCP and consumes one additional FBP hop. The
accepted maximum is 20 hops for all FBP relationships.

The tagged container build publishes `latest`, the tag-specific
`v1.5.0-with-proxy` image and `development-latest` through the existing release
pipeline.