Grid support

As more an more grids come online using Halcyon code, there's a need for a standard practice and set of recommendations for how to handle differences of opinion on the direction of the project.

Some history first. Back when InWorldz was the primary consumer of the project an issue was opened specifically to get a idea of how to handle differences of goals between InWorldz and Halcyon as a project that was becoming a teenager and starting to stretch some independent muscle. This document has grown out of that conversation.

As we continue to grow and stretch our legs, please bring up issues you run across and we'll see how we can accommodate or help your project grow with us.

Backwards compatability

• Any change made will be reviewed and tested for potential breakage of existing content. If at all possible any breakage of supported features will be either mitigated or minimized. Any unavoidable breakage will be noted in the release notes and be a considered as a reason to bump a major release. ** One such mitigation strategy is to introduce versioning so that we can distinguish between new content or old, and handle the old in the old way. We've come close to doing that a few times, but to date have managed to avoid it.
• Our network protocols and storage definitions add new fields in backwards-compatible ways, and we have been migrating to ProtoBuf formats for both that can easily be extended.

Grid-specific features

In general we have an aversion to incorporating grid-specific code. We highly recommend maintaining a fork if you've got some special grid-specific functionality you want to add on. That said there's a legacy of InWorldz-specific code that has, for good or ill, long ago become part of the codebase and will stay in place to support backwards compatibility as noted above.