This repository was archived by the owner on Jul 28, 2024. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 239
This repository was archived by the owner on Jul 28, 2024. It is now read-only.
Reconsider ChangeInfo hierarchy #1034
Copy link
Copy link
Closed
Labels
duplicateEither a direct duplicate or will be better resolved by another issueEither a direct duplicate or will be better resolved by another issueimprovementImprovement of an existing functionality. See "feature" for new features.Improvement of an existing functionality. See "feature" for new features.scope: coreCore VersionPress functionality like tracking actions, creating Git commits, etc.Core VersionPress functionality like tracking actions, creating Git commits, etc.scope: integrationsDEPRECATED. Since VP 4.0, "plugin support" is the label to use.DEPRECATED. Since VP 4.0, "plugin support" is the label to use.
Milestone
Description
Since the very early days, changes are represented by ChangeInfo objects which are organized in a relatively large and deep object hierarchy:
It makes sense from the OOP perspective, however, when opening VersionPress up for 3rd party plugin support, it might be better to have something simpler in place. For example, a set of functions could describe a change similarly well, perhaps.
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
duplicateEither a direct duplicate or will be better resolved by another issueEither a direct duplicate or will be better resolved by another issueimprovementImprovement of an existing functionality. See "feature" for new features.Improvement of an existing functionality. See "feature" for new features.scope: coreCore VersionPress functionality like tracking actions, creating Git commits, etc.Core VersionPress functionality like tracking actions, creating Git commits, etc.scope: integrationsDEPRECATED. Since VP 4.0, "plugin support" is the label to use.DEPRECATED. Since VP 4.0, "plugin support" is the label to use.
