Bumping package semver based on API change?

Elm-package has a nifty feature where it can diff a package’s API against a previous release to decide how to bump the version.

Are there similar efforts for Elixir? It may be more difficult to do well because, in general, Elixir processes may receive arbitrary, untyped messages. Statically determining whether an API has changed is probably more involved and may ultimately rely on heuristics. Then again, it could be easier than languages with mutability. I don’t expect automatic bumping to always make the best suggestion, but it could probably reduce the risk of forgetting to bump or mistakenly bumping the wrong version field.

I found eliver, which provides a mix task to interactively help you bump the version. However, glancing at the code it looks as though it doesn’t automatically detect an API change.

I’m working on my first package now, so I’m not actively drowning in versioning issues. Just curious if this has been considered yet.

Hmm… You’re giving me ideas. I can see a way to automate this.


In Elixir itself it is an impossible problem, like a halting problem kind of impossible.

However someone could ‘mostly’ do it by reading the typespecs and exported information and get something ‘close enough’, just no one has done it yet, why don’t you be the one? ^.^

To do it properly you really need a fully and strongly typed language, which Elixir is not.

1 Like

Maybe I’ll give a try after releasing a package or two.

Awesome. I think @OvermindDL1 is right that it’s not possible to do precisely, but heuristics can certainly help! After all, if Dialyzer and Idris’ type checker are “solving” impossible problems we can too :slight_smile:

There is a sense in which the BEAM is strongly typed. There are only a limited number of Erlang Terms that can exist on the BEAM. Any Term must be a composition of the basic Erlang types, you can query these terms at runtime.

While you cannot enforce types at the compiler level, you can certainly define them at runtime. I can see a way to automate this by using the existing ExUnit assertions in your tests. In effect every ExUnit test is a sample of the type classes of inputs and outputs of every function. There are ways to create runtime equivalance classes based on a single member of that class.

The tricky part is creating runtimes for both versions so you can do the dynamic type examination.