networktocode/diffsync

Backwards incompatibility: DiffSyncActions is no longer an enum in 1.4.3

eXceediDeaL opened this issue ยท 2 comments

Environment

  • DiffSync version: 1.4.3
  • Python version: 3.7

Observed Behavior

I found that the most recent version 1.4.3 of diffsync probably introduces a breaking change, which is not recorded in release notes.

That is removing Enum from DiffSyncActions's base classes. This change causes backwards incompatibility:

  • DiffSyncActions is not iterable now.
  • Attributes inherited from Enum are not accessible by DiffSyncActions members, e.g. name, and value.

Steps to Reproduce

To make it easier to understand the impact of the breaking changes, I write a short code snippet that reproduces the breaking changes.
The following code runs well in 1.4.2 but gets crashed in 1.4.3.

import diffsync.enum
from enum import Enum

print(issubclass(diffsync.enum.DiffSyncActions, Enum))
try:
    print(list(diffsync.enum.DiffSyncActions))
except Exception as ex:
    print(ex)
print(diffsync.enum.DiffSyncActions.CREATE.name)

Output in diffsync 1.4.2:

True
[<DiffSyncActions.CREATE: 'create'>, <DiffSyncActions.UPDATE: 'update'>, <DiffSyncActions.DELETE: 'delete'>, <DiffSyncActions.NO_CHANGE: None>]
CREATE

Output in diffsync 1.4.3:

False
'type' object is not iterable
Traceback (most recent call last):
  File "a.py", line 9, in <module>
    print(diffsync.enum.DiffSyncActions.CREATE.name)
AttributeError: 'str' object has no attribute 'name'

Maybe recording these changes in release notes helps to avoid user confusion during updating this version?

Kind regrads,

@eXceediDeaL

FWIW, DiffSync 1.4.0 introduced a breaking change itself by converting the DiffSyncActions to an Enum. This was an oversight on our part, not compliant with semantic versioning, and caused issues for downstream consumers of DiffSync (See #101).

DiffSync 1.4.3's breaking change, as described here, was to revert that previous breakage, restoring backward compatibility with DiffSync 1.3.x and earlier.

That said, this absolutely should have been called out more explicitly in the release-notes as a breaking change - my apologies for any troubles this caused you!

I updated the CHANGELOG in 91c37ba and have also added a note to the release summaries for 1.4.0 through 1.4.3.