I’m curious how many minor Elixir versions library authors generally try to support. I’m thinking that a good default is 3 minor versions which will equate to roughly 1.5 years (and is the approach mentioned in Library builders: What versions of Elixir to support? When to stop supporting older Elixir versions? - #3 by Qqwy). And of course the previous versions of a library are still available for users that are unable to upgrade elixir for some reason.
@axelson I’m also a fan of supporting basically 2 major versions of a lib that have different Elixir version reqs. Eg: some library named Foo that has:
Foo v1.5.X supports Elixir 1.10 and 1.11, will receive bug fixes but no new features. Foo v1.6.X supports Elixir 1.12, gets new features.
It depends a bit on how important new Elixir features are to your app.
I’d support anything I could but it depends how easy it would be to just copy-paste the functions from newer Elixir releases to a dedicated
Compat module namespace. I am entertaining the idea for a long time and I think it can work out fine.
Having said that, I’d aim for current version plus 2 versions behind, e.g. 1.12, 1.11 and 1.10.
Mind if I hijack the thread to get some clarity? Say 1.9-1.11 your library works, but 1.12 breaks it. In your example, I could create a 1.6.x branch and specify it as tested for 1.12, but how would that work for something like hex.pm? It would only display the latest version of my lib, wouldn’t it? And would that be left up to the developer to see that they’d have to downgrade their version?