[erlang-questions] OTP Version

[Tristan Sloughter]

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
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions