CubicleSoft recognizes that managing software is difficult and maintaining systems to always run the latest bleeding edge software can be prohibitively expensive and that developing software takes time and effort. This document aims to cover the official policies regarding intra- and inter-library compatibility, backward compatibility breaks, and backward and forward compatibility so that you, the user, have confidence in using CubicleSoft software on your systems.
Legal: When in conflict, the license associated with CubicleSoft software supersedes the legally bindng statements made in this document.
Intra-library compatibility refers to the level of compatibility with importing two separate libraries from the same organization. In general, CubicleSoft software works with CubicleSoft software. That is, any two libraries from different CubicleSoft projects can generally interoperate in the same environment as other CubicleSoft libraries. Effort is made to uniquely name CubicleSoft library classes in a no-conflict intra-library compatibility manner.
Inter-library compatibility refers to the level of compatibility with importing two separate libraries from different organizations. In general, CubicleSoft software makes little to no effort to work in tandem with software products from other organizations. The reason for this is that the number of published repositories on GitHub makes it possible to develop most applications entirely using CubicleSoft software libraries. See the intra-library compatibility policy above. That said, it is entirely likely that CubicleSoft software applications and libraries won't conflict with another organization's software but this is not a guarantee.
Some CubicleSoft products are extensible with plugins, extensions, or the like. When this happens, CubicleSoft generally spells out the recommended design for reducing the potential for conflicts.
Legal: CubicleSoft software generally does not conflict with CubicleSoft software but may or may not conflict with software from other organizations.
A backward compatibility break, aka BC break, refers to the intentional decision to break backwards compatibility in an application or library in a way that breaks many applications that depend on the affected software. Upgrading to the latest version of a library or application that has a BC break in it is the single greatest source of wasted time in the tech industry.
CubicleSoft has a very strong policy of not introducing BC breaks for two reasons: First, CubicleSoft software is generally stable and future-proof by design. Second, CubicleSoft eats its own dog food. BC breaks are not fun to deal with, so CubicleSoft is quite adverse to making them itself. Across hundreds, perhaps thousands, of projects (not all are on GitHub), CubicleSoft has made maybe a half-dozen BC breaks over decades of development effort.
Exceptions are made at CubicleSoft when there is no other option but to do a BC break. For example, a security bug that forces a BC break. Or a bad design decision was made in a way that produces a series of application bugs. Most, but not all, BC breaks can be avoided with some clever workarounds which allows existing software to continue functioning while writing future code that avoids the issue altogether.
Legal: CubicleSoft generally avoids backward compatibility breaks but will occasionally make them.
In general, the rule of thumb used by CubicleSoft for backwards compatibility is support for software and hardware configurations that have not reached End Of Life (EOL). EOL is the date that a software vendor or hardware manufacturer declares they have ended support for a specific configuration. Past any particular EOL date, support for a specific configuration may terminate unexpectedly.
An example of this policy is how CubicleSoft supports the PHP scripting language. This page shows the currently supported versions of PHP and the official EOL timetable for that language. For CubicleSoft software, it is reasonable to expect software written in PHP to work on the currently supported versions. It is unreasonable to expect the same software to work on PHP 4.x as the last release was in 2008, is no longer supported, and very little of today's software works on PHP 4.x anyway.
Another example of the policy is Operating System support. Microsoft infrequently announces new OSes and retires older OSes. Other OS vendors have more definitive retirement schedules. CubicleSoft supports current OSes that have not reached EOL.
Legal: Past an End Of Life (EOL) date of any CubicleSoft software product or any of its dependencies, there is no guarantee of functionality.
On the flip side of the coin is forward compatibility. In general, CubicleSoft is a cautious software development company, generally leery of brand new technologies. When something brand new comes out, CubicleSoft waits a while to adopt it.
For example, when a new version of PHP is announced (e.g. 8.0.0), CubicleSoft waits until the fourth sub-release (e.g. 8.0.4) is put into production before moving to it. From experience, that is the release where most of the serious bugs have been squashed and the product has stabilized into a general holding pattern.
For a new OS, CubicleSoft will generally not support it until 4 to 6 months have passed the original release date. Also, Long-Term Support (LTS) versions of the software are given higher priority as they signal a dedication to the product that non-LTS versions are not given.
Waiting for a piece of software to mature a bit before using it has advantages. Specifically, bugs don't crop up mid-development. As a result, there are fewer delays in waiting to have specific bugs get fixed before continuing to develop software and also avoids developing hacks/workarounds for the bugs.
The results of waiting a little bit before adopting new versions of software are reduced time costs and cleaner, more maintainable code as well as a higher quality product.
Legal: Before CubicleSoft moves to a new major version of a software product, there is no guarantee of functionality.
Just because software falls outside of the support window does not mean it will stop working on a specific configuration.
CubicleSoft writes software in a way that tends to have longevity outside of support windows because broken software, whether by design or accident, is terrible to work with. CubicleSoft also recognizes that upgrading systems can be costly so CubicleSoft prefers stable software with a long shelf life.
In general, CubicleSoft software runs on a wide array of configurations that have not been specifically tested for. As a result, the software has a pretty good chance of working just fine on your system even if support hasn't been officially declared. But this is not a guarantee and you should consider updating outdated software and/or hardware to something more recent.
Legal: CubicleSoft software may or may not function as expected on unsupported hardware or software combinations.