v1.4.0

Monitors and profiles

• mhub profile edit now prompts for the profile name, so a profile can be
  renamed from the CLI the same way a monitor can. Pressing Enter keeps the
  current name. This brings the CLI in line with monitor edit and the web GUI
  edit form, which already allowed renaming.
• mhub profile clone [--deep] is now available from the CLI. It performs the
  same shallow and deep profile clone the web GUI already offered: a shallow
  clone (the default) copies the profile's type and configuration and links the
  clone to no monitors, while --deep also links the clone to the same monitors
  as the original. Both routes call the same SQLiteHandler.clone_profile the
  web GUI uses, so the two interfaces cannot disagree.

Documentation

• Documented sequential and parallel event processing in the monitors guide.
• Added the Rust port assessment and the LinkedIn announcement copy under
  docs/.

v1.3.0

This release tightens how monitors are created and configured, and documents the
profile model.

Monitors and profiles

• A monitor now requires at least one profile. The profiles relationship is the
  monitor_profile_map join table, not a column on monitors, so nothing
  stopped a monitor from being created with none. Such a monitor started, found
  nothing to dispatch to and exited, which the CLI reported as "started" and the
  web GUI as an unexplained startup failure. The CLI and the web GUI now enforce
  the rule on create, edit and start, monitor test reports missing profiles
  instead of passing with nothing tested, and a scheduled monitor fails the start
  like an instant monitor rather than silently idling.
• The remote path is now conditional on the linked profiles. A remote profile
  copies files between the monitor path and the remote path; a command profile
  runs a command and never touches it. Both interfaces now pick the profiles
  first and ask for the remote path afterwards: the CLI prompts for it only when
  a remote profile was selected, and the GUI labels it accordingly (the profile
  picker, name and monitor path moved outside the Streamlit form so the label
  updates live). A remote path left over from an earlier remote profile is kept
  rather than cleared, so re-linking a remote profile does not mean re-entering
  it. A monitor that has a remote profile but no remote path is refused at start,
  and a NULL remote path is normalised to an empty string when read.

Documentation

• New profiles guide covering the profile model, the profile properties and the
  two profile categories (remote and command).
• New web GUI getting-started page with screenshots of a profile form, the
  monitor wizard, the monitor list and a monitor log.
• Updated the monitors guide for the "at least one profile" rule and the
  conditional remote path.

Continuous integration

• The unit tests run on every pull request and every push to main
  (.github/workflows/test.yml), through the same make test-unit target a
  developer runs locally, so CI cannot drift away from it.
• The unit tests no longer depend on local fixtures or a local rclone install.
• The GitHub Release body is generated from the matching CHANGELOG.md section
  by utils/release_notes.py. A tagged build fails when the tag, version.py
  and the changelog disagree, so a mis-tagged release cannot publish the wrong
  notes.
• Workflow actions bumped to actions/checkout@v7 and
  actions/setup-python@v7.

The database schema is unchanged (1.0.0), so mhub database upgrade is not
required for this release.

v1.2.0

This release is about packaging and documentation: the GUI binary is now a
single download that also carries the complete CLI, and the manual is published
as a website.

GUI and CLI binaries

• The GUI binary is now called mhub-gui (previously mhub-webgui) and is a
  superset of the CLI: it dispatches the same commands, so mhub-gui database init works exactly like mhub database init. One download is enough to
  manage MonitorHub from the command line or from a browser.
• The Windows GUI ships as an onedir folder in a versioned zip
  (mhub-gui-<version>-windows.zip) instead of a onefile executable. A onefile
  build of the Streamlit application spends several seconds unpacking itself on
  every start; the folder starts immediately.
• The Linux GUI stays a single self-contained file.
• build_project.py gained an --layout onefile|onedir option and an all
  target. A failed build now stops immediately with an explanation instead of
  continuing to the next target.

Continuous integration

• The GUI artifact is built and published by CI, alongside the CLI.
• Workflow actions were moved to Node 24 runtimes.
• utils/check_actions.py audits the Node runtime every workflow action
  declares, so an action that drops Node 24 support fails the build instead of
  being force-migrated by GitHub.
• A Dependabot configuration keeps the workflow actions current.

Documentation

• The manual is published with MkDocs Material to GitHub Pages:
  https://transparent-systems.github.io/monitorhub/
• The build runs mkdocs build --strict, so a link to a page that does not
  exist fails the build rather than shipping a broken manual.
• New pages cover installation, the first monitor, remote and command profiles,
  the CLI, the database, placeholders and the architecture.
• The README gained a table of contents and links to the published manual.

v1.1.0

Added Streamlit web pages: home, info, logs, monitors and profiles.
Start Streamlit with:
.venv/bin/streamlit run app/webgui/home.py

v1.0.2

Bump version to 1.0.2

v1.0.1

Bump version to 1.0.1

v1.0.0

Release v1.0.0