[erlang-questions] OTP Version

[Michael Truog]

On 07/17/2014 03:49 PM, Tristan Sloughter wrote:
> 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?

My main concern is that being unable to version all erlang applications together helps to obscure what selection of erlang applications should be used in production, making the open source project less transparent and more of a proprietary project.  That can help generate consulting revenue for the few people that may track what erlang applications are best together, but would further limit the growth of the community due to a decrease in transparency.  That pursues an idea that the open source community should only be a community of alpha/beta testers.  I understand the source repo has a single version file which is meant to track a version, but if that version is never used by anything in production, it becomes meaningless.

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