Interfaces, Abstract base classes, and breaking changes

Goal here is not to start a big debate on Interfaces vs Abstract base classes :)

Generally, interfaces tend to be cleaner, but they don't rev well. So we often use abstract base classes (e.g. Package instead of IPackage). This is important when the breaking change bar is very high, which it generally is for Microsoft products.

However, it may very well be that NuPack doesn't need to play by those rules of super high breaking change bar. If we make the statement that there will be breaking changes from v1 to v2, then we have a lot more flexibility. One argument in favor
of this is that NuPack is primarily a tool rather than an API. Of course, it is an API too, but few will write directly to it (hence be exposed to breaks).

Bottom line: we're discussing the possibility of switching to using interfaces and accepting that we will likely have breaking changes.

I am a big fan of interfaces.. I agree that the internals of the tool do not need to conform to some of the same constraints your team normally must deal with. It could be a good time to try out the interfaces.

This may be a different thread, It would probably would be good to define the areas where we want to avoid breaking changes... ie. nuspec schema, powershell commandlets. anything else????