Releases and maintenance
If your IT or change-advisory team needs to know how First Six ships updates, whether there are maintenance windows, and how much warning you get before something changes, this is the page. It is the operational companion to how we change the platform safely, which covers the testing and review behind each change; this page covers the schedule, the downtime, and the notice.
First Six ships continuously as a single live version, with no scheduled maintenance windows and no planned downtime for a normal release. Every institution is always on the current version, so you cannot opt out of an update, but you get advance notice of any change that affects how your staff or students use the product, and every change is tested and reversible before it reaches you.
How often we ship
First Six does not run on a fixed monthly or quarterly release train. Improvements and fixes ship continuously, as soon as they are ready and have passed the verification checklist, which in practice is often several times a week. There is one live version of First Six and everyone is on it.
This is deliberate. A single continuously-deployed version means there is no fleet of older versions quietly running an unpatched flaw, and never any question about which version your institution is on: a fix reaches every user the moment it ships.
Planned downtime and maintenance windows
First Six does not schedule maintenance windows, and a normal release does not take the service down. The application is statelessNo user data lives on the application servers themselves; it all sits in the database. A server can be replaced or updated without losing anything. and deploys are rolling, so new code is brought in without an outage, and the data behind it is never touched by a release. Database changes are designed to apply online and to be reversible.
In the rare event that a change ever genuinely required brief planned downtime, we would schedule it outside Australian business hours and give you advance notice under the policy below. We reserve the right to suspend the service for urgent maintenance or to protect its security, as set out in the terms of service, but that is an exception, not a routine.
One version for everyone: can we opt out of an update?
No, and that is the point. Because there is a single live version, an institution cannot defer an update, pin to an older version, or opt out of a release. In return you are always on the current, fully-patched version, with no version fragmentation and no upgrade projects to run.
What you do control is your own instance's content and configuration, the part of First Six that is yours: your six weeks of content, branding, term dates, and feature toggles. Those changes are made by you (or requested from us) and take effect on their own schedule, separate from platform releases. See making changes to your instance.
Who is affected by a release
- Every institution, at the same time. Releases are not rolled out institution by institution; the current version is the current version for everyone.
- Backward-compatible by default. A normal release does not require any action from your team, your students, or your IT. Existing sign-ins, links, and integrations keep working.
- Students and staff simply see the improved product the next time they open it. There is nothing to install or update; First Six is a web app and, on phones, an installable web app that updates itself.
How much notice you get before a change
Notice is proportionate to how much a change affects you. These are the commitments:
| Kind of change | Notice | How you hear about it |
|---|---|---|
| Routine improvements and bug fixes | None needed | Recorded in the changelog |
| Material changes — anything that changes how your staff or students use the product, or removes or significantly alters a feature | At least 10 business days | Your nominated support contact, plus the changelog |
| Breaking changes to integrations — SSO, SIS / roster sync, webhooks, or the API | At least 30 days | Your technical contact, plus developer docs and the changelog |
| Security or emergency fixes | May ship immediately | Notified as soon as practical; via the status page if there is any service impact |
| Incidents (unplanned disruption) | Per your agreement | Your agreed contact within the window in your agreement, plus the status page. See status and uptime |
A wording tweak, a layout polish, or a performance fix is routine and just lands in the changelog. A change is "material" when a staff member or student would have to do something differently because of it, or when a capability they rely on is being removed or meaningfully altered. When in doubt, we treat it as material and give notice.
Emergency and security changes
Protecting students and their data comes before the notice schedule. A fix that closes a security issue or resolves an active incident may deploy immediately. When that happens, the same evidence trail is still completed (the change is tested, recorded, and reversible), and we notify you as soon as it is practical to do so. An emergency reorders the trail; it never removes it.
Testing before a release reaches you
Every change runs a fixed verification checklist before it ships, and a separate non-production environment stands for pre-production testing. Full detail is in how we change the platform safely.
There is no customer-facing staging environment today: institutions do not currently get a private sandbox to preview a release before it reaches production. First Six tests changes in its own non-production environment. If a per-institution preview environment is something your change process needs, tell us during onboarding so we can plan for it.
Integrations and deprecation
Changes that touch the systems your IT team connects to First Six (single sign-on, student roster sync, webhooks, the API) are held to the longer 30-day notice above, because they can require work on your side. Where an integration or an API field is being retired, we give the deprecation window in that notice and keep the old and new behaviour working together for as long as the window allows.
Where to see what changed
- Changelog — a dated record of what shipped.
- Status page — current service status and incident history; you can subscribe there for updates.
- Roadmap — where the product is heading next.
Common questions
Do you release monthly or quarterly?
Neither. First Six ships continuously as a single live version, often several times a week, rather than in scheduled batches. Everyone is always on the current version.
Is there downtime when you update?
No. A normal release is zero-downtime: the application is stateless and deploys roll in without an outage, and your data is never touched by a release. We do not schedule maintenance windows.
Can we choose when updates apply, or stay on an older version?
No. There is one live version and every institution is on it, which keeps everyone current and fully patched. You do control your own content, branding, and settings, which change on your schedule, not the platform's.
How much warning do we get before something changes?
Routine fixes are logged in the changelog with no individual notice. A change that affects how staff or students use the product gets at least 10 business days' notice to your support contact. A breaking change to an integration (SSO, roster sync, webhooks, API) gets at least 30 days. Security and emergency fixes may ship immediately, with notice as soon as practical.
Who is affected when you release something?
Every institution, at the same time, and normally with no action required because releases are backward-compatible. Students and staff just see the improved product the next time they open it.
Related
The fastest answer is usually one question away.