akka / akka/akka-http

Document compatibility guarantees

Open
#439 1 comment 0 reactions 1 assignee Claimed by @jrudolph View on GitHub
1 - triaged t:docs
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

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.