How Restless ships, and what "development preview" means.
Software that runs your company shouldn't break your company when it updates. The promises I make about releases, and the ones I don't yet.
Restless is a development preview. That's an honest label, not a disclaimer to hide behind, so it's worth saying exactly what it means: what changes, what I promise not to break, and how updates reach you.
What "preview" means
It means the product is changing quickly. Screens get redesigned, features get added and occasionally removed, and some paths are much better tested than others. I'd rather ship improvements every week and tell you what's rough than polish in private for a year.
It doesn't mean careless with your data. The things that hold your company (its documents, decisions, history and the record of what it did out in the world) are treated as precious from day one.
Promises I make about every release
- Every release is signed. The installer checks the signature before it runs anything, so you know the release came from the Restless build and wasn't tampered with on the way.
- Upgrades wait for running work. An update lets work in progress finish or pause cleanly before swapping anything out.
- Failed upgrades roll back. If the new version doesn't come up healthy, you're put back on the one that worked.
- You can back up and restore. Your company's data can be backed up and restored without needing me.
- Your owner data is never treated as disposable. Test companies get cleaned up automatically. Real companies never do.
What I don't promise yet
Being straight about the other side:
- Screens and workflows will change, sometimes a lot.
- Some paths are well tested and some are new. I'll say which is which.
- Interfaces for developers (the command line, connections and APIs) may change between releases.
How I decide what ships
Every change goes through the same checks before it reaches a release, run on my own machines rather than rented ones. But checks passing isn't the bar. The bar is that the thing actually works when someone uses it: that a company produced the document, or the page actually loads on a phone. A green test that doesn't prove the outcome isn't evidence.
When something does break, the fix goes into the next release rather than being patched by hand on one machine, so everyone gets it.
How to tell me what broke
The most useful thing you can do with a preview is tell me where it fell over. The repo has issue templates for setup help and for telling me what you want to run with it. A description of what you were trying to do is worth more than a perfect bug report.