Versions
A hosted tool has one draft and any number of published versions.
- The draft is the code you are working on. Every build in the AI Builder and every Replace Code replaces it, and the previous draft is gone — there is no history of drafts. The Sandbox runs the draft. No course ever does.
- A published version is a permanent, numbered copy of the draft: 1, 2, 3, and so on. A single number, not
major.minor.patch. Publishing records the draft as the next number; the draft itself is unchanged and you keep working on it. A version's code can never be edited or deleted — a fix is the next number.
The Versions tab lists them. New Version publishes the draft; the only choices are the version's visibility and a note saying what changed.
Visibility
Who a version is for decides what happens when you publish it:
| Visibility | Who can add it to a course | What publishing does |
|---|---|---|
| Private | Only courses you teach yourself — see your own courses. | Published at once, with no review. It becomes your pilot. |
| Unlisted | Instructors who have a sharing code for your tool. | Sent for review. Once approved, it becomes the current version. |
| Public | Any instructor, through the Voshi catalog, or with a code. | Sent for review. Once approved, it becomes the current version. |
The default is private. You can change a version's visibility later from its Edit drawer: moving a private version to unlisted or public sends it for review; moving a pending one back to private takes it out of review and publishes it as your pilot.
Review
An unlisted or public version starts in Pending review. Voshi looks at what the tool does before it reaches instructors who are not you, and the review is where a tool is checked against the expectations of the educational space — what it stores about students, what it shows them, that it does what it says.
While a version is pending it cannot launch: a course pinned to it (which only happens for one of your own courses) shows staff a message that the version is waiting for review, and students that the tool is not enabled right now. You can keep building — the draft and the Sandbox are unaffected — and publish further versions; each is reviewed on its own.
When a version is approved it becomes Published, and if it is unlisted or public it becomes the current version.
Current and pilot
Two of your versions have a special role, and the Versions tab marks them:
- current is the version a course gets when an instructor adds your tool, whether from the catalog or with a code pinned to current. It is the most recently approved unlisted or public version — or whichever eligible version you chose with Make current.
- pilot is the version your own courses get with a code pinned to pilot. It is the most recently published private version, or whichever you chose with Make pilot.
Neither pointer moves when you publish something new that is still in review, and neither moves a course that has already adopted a version.
Statuses
| Status | Meaning |
|---|---|
| Pending review | Waiting for Voshi's review. Does not launch. |
| Published | Launches. New courses adopt it when it is current. |
| Deprecated | Still launches, but staff who open the tool are offered an upgrade to a newer version. |
| Disabled | Does not launch. Staff are offered the upgrade; students are told to ask their instructor. |
Deprecate and Disable are in a version's Edit drawer. Deprecating is how you move courses forward: nothing else prompts an instructor to upgrade, not even a newer published version. A deprecated version has an Upgrade courses to choice, which names the version its courses are offered (the current version if you leave it blank). Disable a version only when it must stop running — a course on it cannot use your tool until its instructor upgrades. The current or pilot pointer moves to the next eligible version when the version it pointed at is deprecated or disabled.
How courses adopt a version
When an instructor adds your tool to a course, the course pins to a version — the current one, or the one the sharing code they used names — and keeps it. From then on every launch in that course runs that version: through the whole term, and in every term the course is copied into, which inherits the pin.
Publishing a new version does not change any course. Courses are never upgraded automatically, not when you publish and not when a course rolls forward into a new semester. The instructor signed up for a specific set of features; swapping them out under a running course would be disruptive, and most universities value stability and consistency over new features. Upgrading is strictly opt-in: when you deprecate the version a course runs, its instructor sees the offer at their next launch, and the course moves only when they accept.
So at any moment several courses can be running several versions of your tool, and that is normal. Two consequences for your code:
- Read what older versions wrote. A course that upgrades keeps its stored
api.storagerows, so new code must accept the shapes earlier code saved. Add fields with defaults; don't rename or repurpose them. - Keep handling old locations. A retired location is still placed in courses on older versions.
Your own courses
A real LMS course that you teach — one where the instructor is you, signed in to the LMS with the same account you use for the dashboard — is a builder course, and it can place any of your versions, including a private one, a pending one, or a disabled one. That is how you run a frozen build with real students before it goes to anyone else: publish the draft as a private version, and add the tool to your course with a sharing code pinned to pilot (or to that version's number).
Only the Sandbox runs the draft. A real course, even yours, always runs a published version.
In practice
- Build and test in the Sandbox until the draft is right.
- Publish as private and pilot it in a course of your own, if you have one.
- Publish as unlisted or public (or change the pilot's visibility) to send it for review. Once approved it is the current version, and new courses adopt it.
- Keep building. The draft moves on; the published version does not.
- Fix a problem by publishing the fix as the next version. To move existing courses to it, deprecate the old one: their instructors are offered the upgrade at their next launch.