Releases and versioned knowledge
If your product ships in versions, the right answer depends on which version a buyer is asking about. Releases let you tell Appricity which knowledge describes which version, so agents don't quote last year's behaviour as today's.
What is a release?
A release is a named version of your product, such as v3.2, with:
- a version label (sorted as a version number, so v3.10 comes after v3.9);
- a release date;
- a status: planned, released, superseded, deprecated or cancelled;
- an optional predecessor, the release it replaces;
- a changelog.
One released release is marked current. That's the version agents assume when nobody says otherwise.
How do I create one?
Open Knowledge → Releases and choose Create release. Give it a version label, a date, a status (planned or released), optionally its predecessor, and the changelog. From the list or the release's own page you can then:
- Mark released a planned release;
- Set as current a released release (the previous current one becomes superseded);
- Deprecate a release that should no longer be used.
How do I tie knowledge to a release?
Each source has a version binding, set on its detail page under Version binding:
- Agnostic: always relevant, whatever the version (the right choice for company background, pricing policy and so on).
- Current: follows whichever release is current.
- Bound to a specific release: only relevant to that version.
- Bound to a release range: relevant from one release to another.
When you import files in bulk you can set a release and binding for the whole batch.
A source bound to a release that has since been superseded or deprecated shows a Stale badge, so you can see what needs refreshing.
What does a release page show?
- the changelog;
- coverage: how many sources are bound to it directly or through a range, and how many product-graph entity versions it has;
- the status history, with who moved it and when;
- coverage gaps compared with its predecessor, where version-specific product information hasn't been carried forward.
Do I need releases at all?
No. If you sell a single, continuously updated product, leave every source agnostic and ignore releases. They exist for teams whose buyers really do run different versions.
How does this affect answers?
When a conversation is about a particular release, retrieval only uses passages whose binding matches it, plus agnostic knowledge. Everything else is left out, so an answer about v3 isn't built from v2 documentation.