Document compatibility guarantees
- Dominant language
- Scala
- Stars
- 1.4k
- Forks
- 584
- Avg merge
- 14h 33m
- Merged PRs (30d)
- 24
Description
Initial thinking:
- be not as strict as akka proper
- try to keep binary compatibility
- not keeping it would somewhat discourage building third-party extensions which would be hard to use if we don't keep our API binary compatible
- but try to be pragmatic about it
- we've got some traits/interfaces that are kept non-final for code organization reasons but that evolve in a way that custom implementations would break -> collect all those traits (all model things, `Directives` and `XYZDirectives`) and discourage from extending
- binary compatibility may be trade-off
- e.g. recent `Multipart` change which is a binary-compatibility breaking change which was somewhat unlikely to be noticed
- introduce `@experimental` documentation or annotation marker that marks API that is not yet stable (#438)
- we should also set some guidelines how to handle methods created like this
- Does `@experimental` API need to be promoted after a fixed period of time?
- What would be the reasons to get rid of `@experimental` API?
- hard to maintain
- bugs / generally unsupported
- define deprecation cycles for stable APIs to be phased out
Contributor guide
Assessment
This issue has not been assessed yet.