Skip to content
OclavexOclavex Docs

Products & versions

A product is something you license — your app, a module, an edition. It’s identified by a product code plus a product version; the two together are unique. Versions are dot-separated numbers, one to four parts (1, 1.0, 1.2.3.4) — prerelease or build suffixes like 2.1.0-beta are rejected. A product carries its own features and metrics, and moves through a lifecycle:

Draft → Preview → Published → Disabled → Archived

A product starts in Draft; set it Published when it’s ready to be granted to customers. Publishing is refused while any of the product’s linked catalog features is still Draft — the most common publish failure — so publish the features first.

The arrows show the usual order; every move except one is reversible. A product can go back to an earlier state at any time: publish one too early and you can set it straight back to Draft, correct the definition, and publish it again. Entitlements already granted and licenses already issued keep working while the product sits in that earlier state. The portal repeats this warning when you confirm the move.

Archived is the exception, and the only one. An archived product can never be brought back, so choose Disabled when a product should leave the market for now, and Archived only when that decision is final.

A version is a separate product

Section titled “A version is a separate product”

A new version isn’t a flag on an existing product — it’s a separate product that shares the same product code and carries its own version number. All versions of a code form a family: each new version points back to the family root (the first version), and the feature catalog is anchored there, so feature definitions are shared by every version. Duplicating a product as a new version copies its features and plan sets — but not its metrics, monitored assets or property values, which must be re-created on the new version. Created fresh or duplicated, you can evolve 2.0 without touching the licenses already issued against 1.4.

APP · 1.0 the family root — the first version own plan sets · own licenses APP · 2.0 a separate product, same code own plan sets · own licenses APP · 3.0 a separate product, same code own plan sets · own licenses each version points back to the family root Feature catalog — one per family anchored at the family root; every version shares its definitions, so feature codes carry across versions anchored here Changing 2.0 never touches the licenses already issued against 1.0.

That independence is the point: changing a newer version never silently alters what an existing customer is licensed for.

Where it runs

Section titled “Where it runs”

A product can declare application scopes (e.g. Desktop, Mobile, Cloud.Production) that restrict where it may be activated — useful when the same application ships to very different targets.

How it relates

Section titled “How it relates”
  • Defines → features and metrics that belong to this version (feature definitions live in the family’s shared catalog).
  • Priced by → plan sets, owned by the product’s suite.
  • Granted via → entitlements, which snapshot the product’s features at grant time.