ARC Best Practices » Inter-Project Compatibility
en

Inter-Project Compatibility

With what releases of what other projects or products does this project interoperate? Using what interfaces? (The ARC will want a reference to the ARC case approving these interfaces, if they're already approved, or a specification and proposed stability classification for the interfaces otherwise.)

Can this version co-exist or interoperate with earlier and later versions? with alternative implementations (perhaps by other vendors)? Is switching between installed versions or implementations possible? What is involved? It has often proven desirable for both sides of an interface to know the version number of the other. For example, a library and a client might each be used with a compatible, but older version of the other. Versioning allows them to adapt to the opposite side's capabilities.

Does the project move, disable, delete, circumvent or change any files, components, or services outside the project? These actions are of serious architectural concern. Discuss with the owners of the affected component what alternatives are possible.

Does the project use any interfaces that are private to another consolidation? (For example, a driver might use kernel structures, an application might read or write /dev/kmem, or might trap directly into the kernel, instead of via libc functions.) These are likely to cease functioning, and therefore are typically disallowed. Interfaces between products should be versioned, suitable for the Contract Private or Committed Private stability classification.

Tags:
Created by admin on 2009/10/26 12:07
Last modified by admin on 2009/10/26 12:07

Collectives

Community Group arc Pages


XWiki Enterprise 2.7.1.34853 - Documentation