Proposed breaking changes for Mapperly 4.0

[latonz]

A list of proposed breaking changes for Mapperly 4.0:
To be discussed, if a particular change on the list leads to major discussions, we should create a separate issue.

1. ✅ Strict Mappings by default (level warning) (strict mappings by default #1353)
   1.1. Change the default severity of RMG012: Source member was not found for target member to Warning
   1.2. Change the default severity of RMG020: Source member is not mapped to any target member to Warning
   1.3. Change the default severity of RMG037: An enum member could not be found on the source enum to Warning
   1.4. Change the default severity of RMG038: An enum member could not be found on the target enum to Warning
2. ✅ Replace MapPropertyAttribute.ctor(string[], string[]) with MapPropertyAttribute.ctor(string, string[]) and MapPropertyAttribute.ctor(string[], string) since member paths are only supported on one side by Mapperly (Replace invalid MapPropertyAttribute constructors with valid versions #1354).
3. Change the default of MapperAttribute.AutoUserMappings to false.
4. Change the default of MapperAttribute.PreferParameterlessConstructors to false
5. Change the default severity of RMG060: Multiple user mappings discovered without specifying an explicit default to Error (requires MapperAttribute.AutoUserMappings default to false due to Before/After-Map).
6. ✅ Change the enabled conversions check for underlaying enum types from ExplicitCast to a new EnumUnderlayingType conversion (Option to disable EnumUnderlayingType conversions #1176, add enum underlying type conversion #1352)

[wrestlerdude]

What is the justification of no. 3?

[latonz]

@wrestlerdude the idea is to get to a more explicit API and prevent accidental / non-intuitive use of a mapping method by Mapperly.

[devtekve]

Why do you consider changing the severity to Warning a breaking change on no. 1? Am I missing something? 🤔

[latonz]

It is not really a breaking change, but we decided to postpone this change to the next major release since it may still need adjustments by all users that have TreatWarningsAsErrors enabled (which AFAIK is quite common).

[latonz]

We decided to not implement 3), 4) and 5) for now to keep breaking changes limited. All other breaking changes are merged.