Improve documentation of generic fields #4651
Conversation
| */ | ||
| private?: boolean; |
There was a problem hiding this comment.
I guess this would break the build if it's set, we should have some deprecated state for api changes imo
There was a problem hiding this comment.
It would break the build, but I don't think it's an issue since it would break only for next release. Anyone who's upgrading should be expecting minor changes. Sure, if we remove something significant it would be good to warn in advance, but this is a rename-like change which takes a few minutes to address so I don't think it's worth warning one release ahead with a deprecation. Especially since we do ~2 releases a year.
There was a problem hiding this comment.
in this case it's not a big deal, but would be good to have some strategy to handle the client api changes, breaking builds is not very user friendly, especially when those extensions will be done by 3rd party.
There was a problem hiding this comment.
Breaking changes are expected with new releases. Even going forward I think it makes sense to break it ad-hoc for minor things. It'd take less time for us to update usages for customers than build some kind of compatibility layer. Do you have better ideas yourself?
There was a problem hiding this comment.
Breaking changes are leading to broken functionality, especially in 3rd party modules, and sometimes these are released into production and later discovered by our clients. One example is the Planning IngestRule failure.
When a breaking change does occur, this requires going over all extensions across all repos to make sure nothing is broken. We will need a strategy to avoid these changes breaking things in production because they weren't checked.
There was a problem hiding this comment.
If there are breaking API changes, 3rd party stuff wouldn't build due to compilation errors and could be addressed before it's deployed anywhere. It wouldn't hurt to update usages as we're doing the change, so I'm fine with it.
SDESK-7405