Should major version be increased every time a new rule is added? about format HOT 4 OPEN

Yeah, I think this is correct. @JoeRobich well want to rev the version to 4.0 once all the new rules are in. Hopefully once we are at feature parity with roslyn we won't need to rev the main version number

from format.

I don't agree with this at all. Minor and even patch versions should be allowed to add new features, especially if those features can be turned off. If a project is using dotnet-format for validation during a build (where this scenario could break them), the consumer must take one of the following actions:

1. Lock the version of dotnet-format (disable auto-upgrade)
2. Accept the breaking changes

from format.

2. Accept the breaking changes

The fact that it is a breaking change is what matter here! :) If this tool follows SemVer it would mean a new major version.
This would allow a better flexibility for consumers in locking a version range (essentially pinning the major version) while still allow who prefers to be on latest to do so.

from format.

@alefranz if we were talking about the public API, I'd be more inclined to agree. However, it turns out that most changes made to this package could be considered "breaking" on some definition. The one case where it's reasonably clear that a breaking change does not occur is the addition of a new rule, especially if the command line offers the ability run a set of rules by name. When a new rule is added, the new rule would not actually run or be used until the client updates their command line invocation to include the new rule.

from format.