Sorry for being late in the discussion. I think some part of it reflects what OSGi captures as "API providers" and "API consumers" [1]:
> major — Packages with versions that have different major
parts are not compatible both for providers as well as consumers. For
example, 1.2
and 2.3
are completely incompatible.
> minor — API consumers are compatible with exporters that
have the same major number and an equal or higher minor version. API
providers are compatible with exporters that have the same major and
minor version number. For example, 1.2
is backward compatible with 1.1
for consumers but for providers it is incompatible. Consumers should therefore import [1.2,2)
and providers should import [1.2,1.3)
.
> micro — A difference in the micro part does not signal any
backward compatibility issues. The micro number is used to fix bugs that
do not affect either consumers or providers of the API.
To my knowledge, other languages (like Rust, Go, …) now follow a similar policy. At least they try.
In the Eclipse ecosystem (using OSGi) is is customary to mark packages, which are considered "internal" to a project, to be named "internal" [2]. So while those packages still might be exported from an OSGi bundle, so that other bundles of the same project may use it, it still is clear that the functionality is considered "internal".
So for Hono I think we can follow the same idea of (major, minor, micro) in the context of API consumers and providers. Renaming packages to "internal" doesn't sound very appealing to me in the "1.x" tree. But maybe we could put a "package" info, stating a comment that this package is considered "private".
And maybe technically enforce APIs in 2.x.