mapperly icon indicating copy to clipboard operation
mapperly copied to clipboard

Proposed breaking changes for Mapperly 4.0

Open latonz opened this issue 1 year ago • 4 comments

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) (#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 (https://github.com/riok/mapperly/pull/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 (#1176, #1352)

latonz avatar Feb 23 '24 07:02 latonz

What is the justification of no. 3?

wrestlerdude avatar May 03 '24 13:05 wrestlerdude

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

latonz avatar May 03 '24 18:05 latonz

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

devtekve avatar May 06 '24 15:05 devtekve

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 avatar May 06 '24 16:05 latonz

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

latonz avatar Jul 22 '24 00:07 latonz