We try our best to avoid API changes, as we know you have better things to do with your time. Sometimes however it’s unavoidable, and this is at least an easy one to handle.

The short version is: CloudLayer::Create() now requires a reference to an Atmosphere instance as an additional parameter. This should be really easy to handle in most client code, since you had to have an Atmosphere around to submit the CloudLayer to anyhow.

This does however enforce that a CloudLayer must be associated with only one Atmosphere. You can’t share CloudLayers across multiple Atmosphere instances.

That’s important as we are well underway in our effort to make SilverLining truly thread-safe, allowing you to render multiple Atmospheres across multiple views concurrently. Sharing CloudLayers across Atmospheres would make that impossible… but I don’t know of any customers who were doing that, anyhow.

Another change is that we’ve added some additional “data” parameters to many functions, which is a placeholder for associating operations with specific threads in your application in future releases. These have all been implemented with a default value of null however, so it should not require any changes to your client code at all.

We hope you’ll feel it’s a small price to pay for the thread safety features coming soon in SilverLining 6.