Jeff Walker

Note: this `GetFullName` has moved to `SymbolExtensions.GetFullName()` and `GetTypeSymbolMatched` has moved to `PatternAnalyzer.GetMatchedTypeSymbol()`

Thanks for the offer to help! No, unfortunately, I don't have code to reproduce this. That is a big part of why it isn't already fixed. I also haven't seen...

I definitely think it would be good to include functionality for some kind of range matching. I've created issue #29 for that. Given that different platforms and libraries use different...

One constructor overload that allows this has been marked obsolete. However, for backward compatibility other overloads had to be added that also have this issue.

What are people's thoughts on an `Increment(Part)` method where `Part` is an enum of `Major`, `Minor`, `Patch` vs three methods `IncrementPatch()`, `IncrementMinor()`, `IncrementMajor()`? Also, what should happen to the prerelease...

An alternative API would be a `Next(Part)` method or `NextMajorVersion`, `NextMinorVersion`, and `NextPatchVersion`. Another question is how these should handle starting from prerelease. For example `SemVersion.Parse("1.1.0-rc").NextMinorVersion()`, should that return `1.1.0`...

I'm not familiar with the pros and cons of strong naming. If someone could point me to a blog post or other resource and to examples of what other packages...

In issue #22 the example of dapper was given. Apparently, they publish two versions of the package: https://www.nuget.org/packages/Dapper/ https://www.nuget.org/packages/Dapper.StrongName/

This has been implemented on the `strong-name` branch. However, according to [MS guidelines](https://docs.microsoft.com/en-us/dotnet/standard/library-guidance/breaking-changes#binary-breaking-change) adding a strong name is a breaking change. So this will have to be done as part...

Looking at the times where both a total from Cake and from timing the command were provided, even on the much faster machines than mine, it took 2s to 3.5s...