[erlang-questions] OTP Version
Fri Jul 18 00:49:01 CEST 2014
Right, but it gets confusing because the OTP version IS 17.x.y not 17.
So I'd argue if it can't be determined by the running system it
shouldn't be part of system_info at all.
And to make it more confusing, how does it know it is 17? Could there
not be a mix of 17 and 18 apps in there? Maybe that is rejected?
On Thu, Jul 17, 2014, at 05:43 PM, Michael Truog wrote:
> On 07/17/2014 02:21 PM, Fred Hebert wrote:
> > On 07/17, Tristan Sloughter wrote:
> >> If for all OTP 17.x.y the runtime is going to consider it 17:
> >> 1> erlang:system_info(otp_release).
> >> "17"
> > For reverence, the new method to get the version according to the docs
> > is: http://www.erlang.org/doc/system_principles/versions.html
> > In an OTP source code tree, the OTP version can be read from the text
> > file <OTP source root>/OTP_VERSION. The absolute path to the file can be
> > constructed by calling filename:join([code:root_dir(), "OTP_VERSION"]).
> > In an installed OTP development system, the OTP version can be read from
> > the text file <OTP installation root>/releases/<OTP release
> > number>/OTP_VERSION. The absolute path to the file can by constructed by
> > calling filename:join([code:root_dir(), "releases",
> > erlang:system_info(otp_release), "OTP_VERSION"]).
> > Do note that the version number can be followed by '**', meaning it was
> > patched with otp_patch_apply.
> > _______________________________________________
> > erlang-questions mailing list
> > erlang-questions@REDACTED
> > http://erlang.org/mailman/listinfo/erlang-questions
> So, the idea is that only the source code has a version. The binary
> installation has no minor or release version, unless you check individual
> erlang applications. The reason given so far
> (http://erlang.org/pipermail/erlang-questions/2014-April/078590.html), is
> it is too hard to provide the minor and release version because different
> installations are likely to use different source tree dependencies at
> different versions, so we are likely to lose any dependable information
> about what version set of erlang applications are most stable together.
> erlang-questions mailing list
More information about the erlang-questions