Skip to content
OclavexOclavex Docs
Oclavex is in private preview, available to selected users. Public signup is blocked. Request access at [email protected].

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; only an entitlement set to Draft in the meantime has to wait for the product to be Preview or Published again before it can be published again. The portal repeats this 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 Draft or Archived product can be deleted once nothing active refers to it: no entitlement or offer that is still Draft or Published carries it, it’s in no suite, and no plan set covers it unless that set is archived. Disabled entitlements, archived offers and archived plan sets don’t count, so retiring them is how an archived product becomes deletable. Deleting the last version of a product also deletes its feature catalog, so that version is kept while an active add-on, rating campaign, entitlement, offer or plan set still uses one of its features. Any other product is archived first. The product’s menu greys out Delete and says what still refers to it, and the archive confirmation names the same records. The Products list hides disabled and archived products until you turn on Show disabled or Show archived under Filters and columns.

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 limit which applications may activate it with its allowed applications: a list of application names, one per line, such as Desktop, Mobile or Cloud.Production. This is useful when the same product ships to very different targets.

The name compared is the one your application sends when it activates. The .NET SDK sends its application scope, which is the application’s name unless you set a scope yourself. The comparison ignores case. An application whose name isn’t on the list is refused at activation, and an empty list allows any application. An entitlement can carry allowed applications of its own, set through the API; the two lists are combined.

End of life

Section titled “End of life”

A product version can have an End of life: the last day a new device can activate it. After that day, a device that has never activated a license for the version is refused with license.product_end_of_life, online and offline. Devices activated before keep activating and renewing, so licenses already issued keep working. When a license covers several products, a new device is refused only when every product its application may use is past its End of life. Clear the date to let new devices activate again.

Custom properties

Section titled “Custom properties”

A product version can carry your own key/value pairs, such as a support address, a download link or a note for your team. Each one is Private or Public:

  • Private, the default, stays in the portal and the admin API.
  • Public is sent to your application with every license it receives: the key, the value and its metadata. It isn’t signed, and anyone with the device can read it, so use it for what your application shows, never to decide what it may do.

Neither kind is shown to your customer. A Public value can be up to 1,024 characters long and a Private one up to 5,120, and a save that goes over names the property. Switching a property to Public reaches each application at its next license refresh.

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.