MatrixRTC: Rename MembershipConfig parameters
#4714
Conversation
hughns
changed the title
MembershipConfig parametersMembershipConfig parameters
|
Do we want to make this backwards compatible and introduce a couple of deprecated old properties? |
toger5
force-pushed
the
toger5/rename-membership-config
branch
from
db55170 to
c569893
Compare
toger5
changed the base branch from
develop
to
toger5/membership-manager-one-send-delayed-action
|
Can we make sonar cloud happy event though we use the deprecated fields as fallback? |
We do already have the state `hasMemberEvent` that allows to distinguish the two cases. No need to create two dedicated actions.
- deprecate isJoined (replaced by isActivated) - move Interface types to types.ts
toger5
force-pushed
the
toger5/membership-manager-one-send-delayed-action
branch
from
5acd034 to
052cef9
Compare
toger5
force-pushed
the
toger5/rename-membership-config
branch
from
fc35b3c to
3d60f53
Compare
| /** | ||
| * The period (in milliseconds) with which we check that our membership event still exists on the | ||
| * server. If it is not found we create it again. | ||
| */ | ||
| memberEventCheckPeriod?: number; |
There was a problem hiding this comment.
What happened to this one? Should it be deprecated?
There was a problem hiding this comment.
It was not used anymore (even before this pr it was not used anymore) and I also dont see a reason why we need it. The member event will be observed by listening to state changes. A check period is at best a workaround especially with state_after.
So it should have been deprecated for the last couple of versions and then get completely removed now. (because it was not used in the last versions)
Do you think it is still better to deprecate this and then remove it in the next release?
To me it seemed fine to just drop it now since it had no effect for some time.
|
I am wondering if this should get a breaking change label because of the one property robin mentioned got removed. Technically it does not change anything however since it will continue to be a property with no effect but one can keep it in the config file. Does it make more sense to add the breaking change label to the version that then removes the deprecated fields? |
Checklist
public/exportedsymbols have accurate TSDoc documentation.