Updates

We update your deployment. There is nothing for you to run and nothing to schedule.

What you are told, and when

Release type	Notice
Ordinary	None. It happens and the version changes
Changes the database	Told in advance
Security fix	Told, and moved sooner
Changes behaviour you rely on	Told, with what changed

The release email lists what changed in every version.

What happens while it runs

A short restart, usually under a minute.

Anyone with the console open sees it reconnect. Nothing in progress is lost, because nothing is held in the browser that has not been saved.

Releases that change the database can take longer, proportional to the size of the change and your data. Those are the ones you get notice about.

Asking for a different slot

Two things you can ask for.

To be held back. If your term dates make a particular fortnight impossible, say so with more than a day’s notice.

To go earlier. Some schools want new features as soon as they are available and are happy to be the ones who find the rough edges. Worth it if you have a test-minded ICT team and want influence over what lands.

Your version

Admin, Licence shows the version you are on. That is also the first thing support will ask for.

What a release can and cannot change

Can: add features, add modules, change wording of email templates you have not customised, fix bugs.

Cannot, without telling you: turn on a module you turned off, change your workflow, change your roles or permissions, or alter an email template you have customised.

A new module arrives switched off. A customised template stays customised.

Before it reaches you

Every release runs on our own instance and the public demo before any customer takes it, and is only recommended once somebody has used it. You are never the first deployment a release meets.

Self-hosted

You decide when to update, and you run it. See updating.