tunnelvisionlabs / dotnet-compatibility Goto Github PK

Currently any change in attributes for a publicly-accessible field are considered a breaking change. This is especially useful for ensuring a static field doesn't become an instance field (and vice versa), but may be overly strict.

Versions of referenced assemblies should only change in a manner compatible with the breaking changes policy of the library being checked. The behavior with respect to assembly binding redirection should be configurable.

Currently the implementation does not treat <preliminary/> members in any special way. It would be helpful if the XML documentation file associated with the library could be used to identify items in the previous release which are marked preliminary, and ignore those items during the analysis.

The value of a publicly accessible const field cannot change.

The current build does not report an issue if members are added to an interface.

The current code does not check the assembly name.

The following transformation shouldn't be considered a breaking change, but the current implementation is "too strict" and treats all changes to the base type as a breaking change.

Before:

public class Foo
{
}

public class Bar
{
}

After:

public class Foo
{
}

public class Bar : Foo
{
}

Adding new abstract methods to a class is a breaking change. Note that if the constructor is not publicly accessible in the reference version of the library, this is not a breaking change since external code would not be able to extend the type.

The current implementation throws an exception the first time an issue is detected, and only supports reporting a single issue. It would be helpful to report all issues instead.

Currently any change in attributes for a publicly-accessible field are considered a breaking change. This is especially useful for catching changes to the static and virtual modifiers, but may be overly strict.

The current implementation does not check generic type constraints for methods.

If an interface type IFoo is publicly visible, adding a new interface type IBar to the base interface list of IFoo is a breaking change.

Types may be removed if the assembly is updated to include a [TypeForwardedTo] attribute for the same type in a different assembly.

The current implementation does not check generic parameter constraints for types.

The current implementation only looks at two different versions of the same assembly. It would be nice to look at multiple target builds of the same version of the assembly to ensure certain versions are drop-in (binary compatible) replacements. For example, see tunnelvisionlabs/antlr4cs#87.