[erlang-questions] Fwd: FW: OTP Version

[Andreas Schumacher]

Hi Michael,

I am not sure how to address your concerns, especially your comments
regarding "making the open source project [...] more of a proprietary
project" and "the open source community should only be a community of
alpha/beta testers", other than by referring to Rickard Green's motivations
of the new versioning scheme and OTP_VERSION file on this mailing list a
few months ago [1][2][3].

In general, as long as you use an unmodified / tagged / official OTP
version, you can be sure that the OTP version number in OTP_VERSION is
correct and that you are running a set of Erlang/OTP applications that work
well together, because that combination has been thoroughly tested. Any
change to that release, by patching or changing one or more applications,
results in a modified / untagged / unofficial OTP version for which there
is no official OTP version number, either; in that case, you neither can
nor should rely on the OTP_VERSION file. Furthermore, the one who modifies
an official OTP system is responsible for making its (modified) parts work
together; that has nothing to do with generating consulting revenue.
Although, this could be improved by providing better and more correct
runtime dependency information. As you are well aware of, this is something
we are trying to improve in future releases.

[1] http://erlang.org/pipermail/erlang-questions/2014-February/077675.html
[2] http://erlang.org/pipermail/erlang-questions/2014-April/078585.html
[3] http://erlang.org/pipermail/erlang-questions/2014-April/078590.html

Andreas

---

Andreas Schumacher, Erlang/OTP, Ericsson AB


On 18/07/14 20:39, "Michael Truog" <mjtruog@REDACTED> wrote:

>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
>>
>
>_______________________________________________
>erlang-questions mailing list
>erlang-questions@REDACTED
>http://erlang.org/mailman/listinfo/erlang-questions
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140721/b75c10f0/attachment.htm>