[Proposal] Improve System.otp_release() to return the full otp version

40 views
Skip to first unread message

Ben Stepp

unread,
Oct 7, 2022, 1:41:47 PM10/7/22
to elixir-lang-core
Proposal can also be read on gist.

---

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


Current workarounds:

The current OTP version can be found using the method here.

And this workaround can already be found among the community:


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 DateDateTime, 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.

José Valim

unread,
Oct 7, 2022, 3:11:10 PM10/7/22
to elixir-l...@googlegroups.com
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?

--
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-co...@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.
Reply all
Reply to author
Forward
0 new messages