[erlang-questions] Version numbering scheme change and the implication / Re: [ANN] Erlang/OTP 17.0-rc1 has been released.

[Motiejus Jakštys]

2014.02.07 13:56, Loïc Hoguin rašė:
> 
> These shouldn't be used the way you describe. It's not about Erlang
> vendors, it's about what users put in their releases. If someone uses
> your project in their release, and also had to update, say, the ssl
> application to fix a bug (this happens all the time!), your project may
> suddenly break.

OK.

> Instead you should use this value:
> 
> 1> App = kernel.
> kernel
> 2> application:get_key(App, vsn).
> {ok,"2.16.3"}

This is valid, but works when it is possible and not crazily expensive
to do this at runtime. My use case is a library which has -callback
support. Should we generate behaviours using behaviour_info/1 or
-callback (pre-R15 or R15+)? Sure, we can take the cowboy approach (pun
intended): do not support legacy OTP versions. But what if I can and
want to, and that's the only thing keeping users with R13B04 away from
my library?

Our current solution: put an ifdef in the file which exports the
headers. Now that macro has to be set by the build system.

On the other hand, when thinking about it, I cannot come up with another
example where having the macro would be that necessary during compile
time. There are not many useful constructs since R15B.

Motiejus