Operations

Support and compatibility

How to reach us, how mountOS is versioned and released, and what compatibility to expect when integrating or upgrading.

download.mountos.sh

Versioning

mountOS follows semantic versioning, MAJOR.MINOR.PATCH. The version is compiled into every binary and reported at runtime. While the product is in its 0.x series it is pre-1.0, so breaking changes can land on a minor bump. Read the release notes before upgrading across a minor, and pin an exact version or a major series for reproducible deployments.

Bump	Example	Meaning
patch	`0.1.0` to `0.1.1`	Backward-compatible fixes
minor	`0.1.1` to `0.2.0`	Backward-compatible additions (potentially breaking in 0.x)
major	`0.2.0` to `1.0.0`	Breaking changes

Platform and architecture support

Component	Platforms
Server services (appserv, dataserv, blockserv, gcserv)	Linux only, amd64 and arm64
Client CLI (`mountos`), including the S3 and WebHDFS surfaces	Linux (amd64, arm64), macOS (universal), Windows (amd64, arm64)
Kubernetes CSI node driver (`mountos kubernetes`)	Linux only, amd64 and arm64
macOS app bundle (`mountos-macos`)	macOS universal
Windows app and driver (`mountos-windows`)	Windows amd64

macOS client binaries are code-signed with a Developer ID identity and notarized for Gatekeeper. Windows client binaries are Authenticode-signed with an RFC 3161 timestamp.

API compatibility

Third parties integrate through the client's standards-compatible protocol surfaces rather than the internal protocol. Both are started with mountos gateway --gateway s3,hdfs, or by passing --gateway to mountos mount.

S3: an Amazon S3-compatible API that accepts an S3-compatible request signature. Standard S3 tooling such as the AWS CLI and boto3 interoperates. ListObjects and ListObjectsV2 clamp max-keys to the AWS ceiling of 1000. Multipart uploads follow S3 conventions: every part except the last must be at least 8 MiB, and part numbers run from 1 to 10000.
WebHDFS: the WebHDFS REST API for Hadoop-ecosystem clients, served under /webhdfs/v1. Requests authenticate with an S3-compatible request signature using the service name hdfs. Defaults follow Hadoop conventions, including a 128 MiB advertised block size and an advertised replication factor of 1 (mountOS handles replication server-side, so this value is informational).

Protocol compatibility

Server-to-server traffic uses an internal protocol that supports a backward compatibility window for rolling upgrades. During a fleet upgrade, mixed-version nodes interoperate as long as every node stays inside the supported window. These peers are first-party mountOS binaries, so this protocol is an internal contract rather than a public integration surface.

Upgrade guidance

Pin an exact version (--version X.Y.Z) for reproducible deployments, or pin a major series (--major N) to receive compatible updates.
The installer verifies the published SHA-256 automatically. An artifact fetched out of band should be checked against the published .sha256 or the manifest checksum.
Plan rolling upgrades so that no node advertises a protocol version outside the accepted window.
Because the product is in the 0.x series, treat minor bumps as potentially breaking and read the release notes first.

For anything not covered here, contact support@mountos.io.