What are different compatibility types when creating a COM component?

Can anyone suggest me What are the different compatibility types when creating a COM component? This is because it has been suggested by my senior while creating the COM Component. I think this is important if i will consider about this in advance..

Different compatibility types when creating a COM component No Compatibility - New GUID (Globally Unique Identifier) created, references from other components will not work Project Compatibility -No Compatibility - New GUID created references from other components will not work. Project Compatibility - Default for a new component Binary Compatibility - GUID does not change references from other components will work Default for a new component Binary Compatibility - GUID does not change references from other components will work, Why is it important to use source control software for source code?

Following are compatibility types in COM, Fortunately, VB5 has a mechanism whereby you can specify that it should create a compatible version of the component -- that is, The N1 SPS product enforces call compatibility for components that provide system services. When a system service is updated to refer to a new component, the new component must be call compatible with the original component. it should re-use the existing set of GUIDs and ensure that all methods of each interface remain in the same order and maintain their previous parameter and return types.

• Binary Compatibility - For Backward Compatibility
• Project Compatibility - For Debugging Purpose
• No Compatibility

The way VB compiles a DLL-based server is a little different and, by the time the linker gets to do its thing the type library (and hence the EXE) is no longer locked by VB. Compatibility is a concern when you modify or create new versions of a component that has already been deployed. Each time you modify a component and check it in, you create a new version of that component. I'm not sure why this is the case, but I suspect that this is related to the fact that VB plays fast and loose with the registry in order to make it possible to test and debug ActiveX DLL servers.