use binary compatibility validator

[diklimchuk]

There is a feature of binary validator plugin, that allows to exclude from public API validation some methods that are annotated by a custom annotation. Maybe you will want to make something like @InternalElmslieApi so that library authors would not use APIs that are not stable. This would allow refactoring of methods that are not public API

[dsvag]

There is a feature of binary validator plugin, that allows to exclude from public API validation some methods that are annotated by a custom annotation. Maybe you will want to make something like @InternalElmslieApi so that library authors would not use APIs that are not stable. This would allow refactoring of methods that are not public API

I checked methods before pushing and didn't find methods that need to be marked. What methods are you talking about?

[diklimchuk]

There is a feature of binary validator plugin, that allows to exclude from public API validation some methods that are annotated by a custom annotation. Maybe you will want to make something like @InternalElmslieApi so that library authors would not use APIs that are not stable. This would allow refactoring of methods that are not public API

I checked methods before pushing and didn't find methods that need to be marked. What methods are you talking about?

Any method that aren't supposed to be public api. The ones the you won't keep backwards compatible. Looks like Switcher#switchInternal fits the description.

[rcmkt]

We don't have such method in 3.0 =)

[diklimchuk]

We don't have such method in 3.0 =)

Ah, i looked at elmslie-3-0 instead of publish-elmslie-3.0. Anyway, there's ElmslieConfig.ioDispatchers for example, which looks like an implementation detail and not a public api

[diklimchuk]

We don't have such method in 3.0 =)

Ah, i looked at elmslie-3-0 instead of publish-elmslie-3.0. Anyway, there's ElmslieConfig.ioDispatchers for example, which looks like an implementation detail and not a public api

There are also classes like ElmslieLogConfiguration and ElmslieLogger which look like internal classes

[rcmkt]

ElmslieConfig.ioDispatchers - read-only, and it's not implementation details, the same for ElmslieLogger We are pretty sure to keep all public API as is =)

[diklimchuk]

ElmslieConfig.ioDispatchers - read-only, and it's not implementation details, the same for ElmslieLogger We are pretty sure to keep all public API as is =)

IMHO these things might change in future, and aren't meant to be used by library clients. But this library lived without binary compatibility validation and noone complained, so it's probably fine anyway.