Reuse, not rework
Home

License Awareness


Highly Reusable Software

By activity
Professions, Sciences, Humanities, Business, ...

User Interface
Text-based, GUI, Audio, Video, Keyboards, Mouse, Images,...

Text Strings
Conversions, tests, processing, manipulation,...

Math
Integer, Floating point, Matrix, Statistics, Boolean, ...

Processing
Algorithms, Memory, Process control, Debugging, ...

Stored Data
Data storage, Integrity, Encryption, Compression, ...

Communications
Networks, protocols, Interprocess, Remote, Client Server, ...

Hard World
Timing, Calendar and Clock, Audio, Video, Printer, Controls...

File System
Management, Filtering, File & Directory access, Viewers, ...

Once we document and publish an API as non-experimental, the header file, function name, purpose, interface, and features will not be changed in future revisions. The point is to reduce the risk of rework.

This doesn't mean stale APIs. It just means that when we innovate, we do it using new and variant function names. The old ones continue to be available and work as already documented. Backwards compatibility is always ensured. There is no need to manage multiple versions of a source file: updating to the latest provides the same API and any added features.

If we are legally required to remove a function or implementation from a source file, we will stop distributing the file under that name. Parts of the file which are still distributable will be placed in a new file with a new name.

Developers can opt to access experimental APIs by defining the appropriate librock_EXPERIMENTAL symbol at compile time. Experimental APIs may change as the software undergoes development and testing.