[erlang-questions] Version numbering scheme change and the implication / Re: [ANN] Erlang/OTP 17.0-rc1 has been released.
Motiejus Jakštys
desired.mta@REDACTED
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.
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
More information about the erlang-questions
mailing list