Yagna Compatibility Policy and Guidelines unveiled
What does “compatibility” mean in the Golem context?
The term “compatibility” means “the ability of one computer, piece of software, etc. to work with another.” In Yagna terms, this refers to all components collaborating within the Golem Network.
When designing the scalable architecture of New Golem, we put special emphasis on modularity. We wanted the Golem ecosystem to be built of components, crafted by various parties, and interacting according to the protocols and APIs we have designed. While this might sound ideal, there are downsides to everything. ‘Dependency hell’ is how the industry refers to the struggle to enhance individual elements of the platform without breaking the stack’s functionality in an uncontrolled manner. The more components - the more complex their compatibility relationships are, and the more their authors struggle.
On top of the above challenge which is known to any software engineer dealing with complex systems, at Golem we have the evolving network where nodes are running on different versions of components, with no centralized control over their upgrades. The nodes need to upgrade on their own. These upgrades come with APIs and components evolving, new ExeUnits being added, protocols optimized and plain bugs being fixed... thus adding more compatibility conundrums.
We want Golem App developers to be able to work without limitations or constraints, and with this we do not only refer to building an unstoppable protocol, but also to building a protocol that will not stop them. Applications are to be resilient to Requestor upgrades (while ensuring the app remains compatible with the Yagna APIs), and they should be runnable on as many Provider nodes as possible in the network (which requires those Providers to be compatible with the app).
On the other end, when running a Provider node, users are most likely concerned about how attractive their nodes are to prospective Requestors, and to be attractive users want to be compatible with as many Apps as possible.
Our objective with the Golem Compatibility Policy is to present a packaging, versioning & compatibility model as simple as possible (but not simplistic), and provide Golem network participants with clear guidelines to address their aforementioned concerns.
You are welcome to explore our Compatibility Guidelines and Policy.
Why do we need Compatibility Guidelines?
...To provide Requestors and Providers with simple rules to follow in order to achieve maximum App stability and market coverage. Those interested in more detail are invited to deep dive into our Compatibility Policy and the concept of Requestor and Provider packages versioning.
What’s in the Compatibility Policy?
The Compatibility Policy is a document which declares Golem Factory’s promises regarding software package versioning, compatibility and deprecation patterns.
We have specified a versioning pattern (following the industry-standard Semantic Versioning, where applicable), and defined backwards-compatibility approach that we intend to follow with subsequent releases.
Another important element is the feature deprecation policy. This is an indication for Application Developers as to how obsolete features or elements of Golem stack will be phased out in the release cycle. The purpose of this is to enable Developers to adapt their Golem-compliant software in time for the ecosystem upgrades, and keep their applications operational and attractive.
If you would like to learn more about Yagna - New Golem, go to our handbook
Chat with us chat.golem.network
Follow Golem on Twitter @GolemProject