Thank you for the proposal Ben. Unfortunately I don't think Elixir should expose information the OTP team itself says that it should not be exposed. My suggestion is to bring this discussion to the Erlang/OTP team and convince them to provide an official API for such.
I also think some of the use cases you mentioned could be addressed in other ways. For example, if all you need is a cache key, you can likely cache the hash of the path to the Erlang executable? Or the erts version? On Fri, Oct 7, 2022 at 7:41 PM Ben Stepp <m...@benstepp.com> wrote: > Proposal can also be read on gist. > <https://gist.github.com/benstepp/35d35e09315ca11adad3c7777b516bc0> > > --- > > *Motivation:* > > We were using System.otp_release() as a part of a cache-key in our build > system, and a patch version of an OTP release introduced an ssl handshake > bug in a few of our applications. Once we pinned down the problem, and > cleared our build cache, we realized we should have been using the full otp > version as the cache key, instead of just the major release. > > > *Existing behaviour:* > > - System.version() returns the full elixir version (ie: "1.14.0"). > - System.otp_release() returns the major portion of the otp release > (ie. "25"). > > Note that System.otp_release() just calls > :erlang.system_info(:system_version) which only returns "25" because "The > exact OTP version in the general case is difficult to determine" source > <https://www.erlang.org/doc/man/erlang.html#system_info_otp_release> > > > *Current workarounds:* > > The current OTP version can be found using the method here > <https://www.erlang.org/doc/system_principles/versions.html#retrieving-current-otp-version> > . > > And this workaround can already be found among the community: > > - hex > > <https://github.com/hexpm/hex/blob/b2f23089d6c609465c3b570b4fc40c469b57cc1b/lib/hex/utils.ex#L263-L276> > - dialyzer > > <https://github.com/jeremyjh/dialyxir/blob/b78735f75b325238b7db20d9eed22f018cca5f26/lib/dialyxir/project.ex#L221-L238> > - elsewhere (github code search) > > <https://github.com/search?q=Path.join%28%5B%3Acode.root_dir%28%29%2C+%22releases%22%2C+major%2C+%22OTP_VERSION%22%5D%29&type=code> > > > *Solution:* > > The proposal is to add a better function that can return the full otp > version, somewhere in the core library. > > Here are a few example APIs that do not have any breaking changes, but the > final result doesn't have to be one of these: > > *Example api with options seen in the Version module:* > # Return major version (existing behaviour) > iex> System.otp_release() > "25" > > # Return up to the major version (same as existing) > iex> System.otp_release(:major) > "25" > > # Return up to the minor version > iex> System.otp_release(:minor) > "25.0" > > # Return up to the patch version > iex> System.otp_release(:patch) > "25.0.4" > > # Return up to the pre-release version > iex> System.otp_release(:pre) > "25.0-rc3" > > *Example api with options seen in Date, DateTime, modules:* > # Return major version (existing behaviour) > iex> System.otp_release() > "25" > > # Return the full version > iex> System.otp_release(:extended) > "25.0.4" > > *Example api returning a %Version{} struct instead of a string:* > > Version implements String.Chars so it's pretty easy to get the string > this way. This one is probably my favorite, but it means System.version() > and System.otp_version() would have different call signatures, which may > not be very ergonomic. > # Return major version (existing behaviour) > iex> System.otp_release() > "25" > > # Returns the full version > iex> v = System.otp_version() > %Version{major: 25, minor: 0, patch: 4} > iex> to_string(v) > "25.0.4" > > --- > > I haven't thought too much about how to handle file read/version parsing > failures, but falling back to the current behaviour of returning the major > version might be acceptable. Also, it may be considered too dangerous to > have a file reading and version parsing function like this in the core > library, without :ok/:error tuples which I totally understand (There's an > existing workaround that works for all of our use cases). > > Thank you for your time and consideration, and sorry if something similar > has been requested before; I tried searching, but "version" "otp" and > "release" show up in pretty much every discussion on this mailing list. > > -- > You received this message because you are subscribed to the Google Groups > "elixir-lang-core" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to elixir-lang-core+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/elixir-lang-core/fd52d094-cbcc-4b2a-9939-41774274c159n%40googlegroups.com > <https://groups.google.com/d/msgid/elixir-lang-core/fd52d094-cbcc-4b2a-9939-41774274c159n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "elixir-lang-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-core+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4K4_%2BT2_sN5uo0w__p_rWxgjF5uvfQSeVipjjXG%2Bxe_5A%40mail.gmail.com.
