Summary
While Maincloud is not technically on a bleeding edge or nightly release cycle, the latest version is deployed immediately after a new SpacetimeDB release.
Your only option to not upgrade to latest is to use Standalone or lock in an Enterprise deal for a private node. Each of these have issues:
- Standalone -> Free, but doesn't scale
- Enterprise -> Potentially costly, and overkill for most
The logical conclusion for a vast majority of users is to use shared hosting, a-la Maincloud. It even comes with SLA / Uptime Guarantees if you're a Pro subscriber.
The Issue
I have no doubt that a lot of effort goes into this, but deploying new SpacetimeDB versions to Maincloud without any issue or bugs is a tall order- in fact, it's an impossible order. The new version is being deployed to thousands of modules, all on various runtime versions, and some functionality will be tested live for the very first time in unexpected ways. We can have 1,000 different smoke tests, but they will never handle all of the edge-cases. This has, and will continue to lead to disruptions to Maincloud customers.
If your app or game has paying customers, this type of disruption is not acceptable. Playing devils advocate- some would even argue that these types of disruptions indicate that Maincloud is not a production-ready environment.
Proposal
Similar to #5204 and its related feature request I would love to see a LTS Maincloud instance that is fixed to a specific stable build.
spacetime publish <module_name> --lts
This would prevent new Maincloud version deploys (and bugs) from disrupting production applications deployed on LTS Maincloud, giving potential start-ups and businesses peace of mind knowing their backend infra is stable.
Challenges
I acknowledge this comes with many challenges, so I am looking for feedback and replies in the github thread:
- Does current maincloud transition to LTS or Latest?
- Maincloud will need module migration tool to go from server to server
- Can you only migrate your module from LTS to Latest and not the other way around?
- At what interval is the LTS version updated? What type of key milestones indicate a version bump?
- What type of deploy/patches are allowed on LTS? Bugfixes only? What about QoL?
- What should be the default Maincloud publish functionality, LTS or Latest?
Happy to hear your thoughts. Let's have a discussion.
Requested by @Lethalchip via the SpacetimeDB site.
Summary
While Maincloud is not technically on a bleeding edge or nightly release cycle, the latest version is deployed immediately after a new SpacetimeDB release.
Your only option to not upgrade to latest is to use Standalone or lock in an Enterprise deal for a private node. Each of these have issues:
The logical conclusion for a vast majority of users is to use shared hosting, a-la Maincloud. It even comes with
SLA / Uptime Guaranteesif you're a Pro subscriber.The Issue
I have no doubt that a lot of effort goes into this, but deploying new SpacetimeDB versions to Maincloud without any issue or bugs is a tall order- in fact, it's an impossible order. The new version is being deployed to thousands of modules, all on various runtime versions, and some functionality will be tested live for the very first time in unexpected ways. We can have 1,000 different smoke tests, but they will never handle all of the edge-cases. This has, and will continue to lead to disruptions to Maincloud customers.
If your app or game has paying customers, this type of disruption is not acceptable. Playing devils advocate- some would even argue that these types of disruptions indicate that Maincloud is not a production-ready environment.
Proposal
Similar to #5204 and its related feature request I would love to see a LTS Maincloud instance that is fixed to a specific stable build.
spacetime publish <module_name> --ltsThis would prevent new Maincloud version deploys (and bugs) from disrupting production applications deployed on LTS Maincloud, giving potential start-ups and businesses peace of mind knowing their backend infra is stable.
Challenges
I acknowledge this comes with many challenges, so I am looking for feedback and replies in the github thread:
Happy to hear your thoughts. Let's have a discussion.
Requested by @Lethalchip via the SpacetimeDB site.