[erlang-questions] Version numbering scheme change and the implication / Re: [ANN] Erlang/OTP 17.0-rc1 has been released.
Fri Feb 7 14:08:16 CET 2014
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.
> Instead you should use this value:
> 1> App = kernel.
> 2> application:get_key(App, vsn).
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
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.
More information about the erlang-questions