How Asset Versioning Works in Hibiscus
A friendly walkthrough of how Hibiscus tracks the life of your digital assets — from first draft to client delivery — so nothing ever gets lost or confused.
If you've ever lost track of which version of a file is "the one," or accidentally sent a client an outdated draft, you know how painful asset management can get. Hibiscus solves this with a built-in versioning system that automatically records every meaningful change to an asset and ties it to the work that caused it. Here's how it all works.
The version number
Every asset in Hibiscus has a version number in the format MAJOR.MINOR — two numbers separated by a dot. The first number (major) tracks client-facing milestones. The second number (minor) tracks everything else.
Reading a version number: 2.4
2 = submitted and reviewed by the client once · 4 = four internal changes since then
Every new asset starts at 1.0. From there, two rules govern how the number changes:
-
Major version increases by 1, minor version resets to 0
Example: 1.5 → 2.0
-
Major version stays the same, minor version increases by 1
Example: 1.5 → 1.6
One thing to keep in mind: minor versions can go higher than 9. 1.10, 1.11, and so on are all valid — they always follow the previous number, not decimal arithmetic.
Tags: what's happening to a version right now
Alongside the version number, Hibiscus uses a small set of tags to describe the current state of each asset version. Think of them as status labels. Here are a few tags and what they mean.
in progress: This version is actively being worked on.
placeholder: The version slot exists, but no file has been attached yet.
reviewed: This version has completed a review. It is no longer "in progress."
submitted: This version has been sent to a client.
A version can carry more than one tag at a time (a placeholder version is always also "in progress," for example), but the tags are exclusive in sensible ways — a version that's been reviewed is no longer tagged "in progress," and a version that was under review is tagged "reviewed," not "in review," once the review is done.
How tasks and versions connect
Work in Hibiscus is organized into tasks. Each task that touches an asset will have two versions of that asset attached to it: the version that was already complete when the task began, and the new version that the task is creating. This pairing gives you a clear before-and-after record at every step.
There are five task types, and each has a specific relationship with versions.
✏️ Create
Create tasks produce new assets for review or submission. Any task that has you writing, researching, programming, designing, or producing something new is a Create task.
Receives: The most recent reviewed or submitted version (skipped for v1.0)
Produces: A new minor version tagged in progress, optionally with a file attached. If no file yet, also tagged placeholder.
🔍 Review
Review tasks are used to internally go over the products of a Create task critically and deliberately. Review tasks produce markup, notes, and possibly new questions.
Receives: The latest version, as long as it isn't tagged in progress or placeholder.
Produces: A new minor version tagged reviewed.
📤 Submit
Submit tasks cover communicating with a client for the purpose of sending them new or revised assets for external review and approval.
Receives: The latest version (optionally tagged reviewed).
Produces: The same version, now tagged submitted. The major version increments on the next task.
📋 Project Management
A project management task involves planning, client communication, and administration. Sometimes they manage assets, but frequently they cover a number of other administrative chores.
Receives: Any number of assets at their latest versions (optional).
Produces: Optionally a new minor version of any received asset.
💬 Meeting
Meetings can be internal or external, and while they frequently reference assets, they do not create new assets.
Receives: Any number of assets at their latest versions (optional).
Produces: Nothing — meetings reference assets, but don't create new versions.
⚙️ Other
Tasks that do not fall under any of the previous categories are classed as "Other" tasks.
Receives: Any number of assets at their latest versions (optional).
Produces: Optionally a new minor version of any received asset.
Tracing an asset from start to client delivery
Let's walk through what the full life of an asset looks like in practice. Imagine you're creating a brand document from scratch and taking it all the way to a client submission.
Example: brand document, v1.0 → v2.0
Create task — A new asset is created. Version 1.0 is attached and tagged in progress. When the task wraps up, the "in progress" tag is removed and the file is ready.
Review task — A colleague reviews the document. The task receives 1.0 (completed) and produces 1.1, tagged reviewed. Now there's a clean, approved version on record.
Create task — A round of revisions is needed. The task receives 1.1 reviewed and produces 1.2 in progress. When done, the tag clears.
Submit task — The document is sent to the client. The task receives 1.2, adds the submitted tag. The next version created will be 2.0, since a client submission just happened.
Every step in that chain is recorded and tied to the task that caused it. If someone asks "which version did we send?" or "what changed between v1.1 and v1.2?" — Hibiscus can tell you.
A few things worth knowing
The "latest version" rule
Most task types are only meant to receive the latest version of an asset. You won't be assigning an older, superseded version to a new task — Hibiscus always works forward from the current state of an asset.
Placeholder versions
Sometimes you want to create a task before the file actually exists — maybe you're blocking out work to be done later. In that case, a Create task can produce a version with the placeholder tag, indicating the slot is reserved but not yet filled.
Reviews close the loop
Once a version has been reviewed, it's tagged reviewed — not "in review." The review is recorded as a completed fact. This matters because downstream tasks (like Submit) look for a clean, reviewed version to work from.
Questions or feedback?
If something in the versioning flow feels confusing during the beta, we'd love to hear it. Your feedback directly shapes how we refine this before general release.