[erlang-questions] Fwd: FW: Fwd: Fwd: SSL peer verification in httpc with Mozilla's certificate store

[Andreas Schumacher]

External maintainers can ignore the versions that are not officially
announced as a major release or service package, and for which neither
source/binary packages nor documentation are published on erlang.org.
Nevertheless, in order to increase transparency and to avoid similar
confusion and discussions in the future, we could announce those patch
packages on erlang-questions. Then external maintainers can decide
themselves whether they want to include those packages into their products.

In any case, the next quarterly service packages are OTP 17.3 on September
17 and another service package (probably OTP 17.4) on December 10.

Andreas

On 14/09/14 04:00, "Fred Hebert" <mononcqc@REDACTED> wrote:

>For me the surprise was partly that I expected only patch releases to be
>non-announced, and that feature releases would keep being quarterly --
>i.e. what was changed was not the release frequency, but the versioning.
>
>What actually changed was the release frequency, which was augmented,
>and the announcement frequency remained the same (quarterly).
>
>Now the patch releases are certainly more useful for anyone who has a
>bug that needs fixing, I won't deny that.
>
>What surprised me is that I now need to be a lot more attentive to the
>github tags being applied if I want to keep being able to support
>repositories that tend to follow along with Erlang releases:
>erlang-history for one, or things like buildpacks for Heroku, which let
>people choose the runtime under which they deploy their applications.
>
>I'm guessing the choice is whether to support doing things only for
>quarterly anouncements, or also on patch-level releases.
>
>What does the OTP team feel should be done by external maintainers? If
>I'm maintaining things that depend on your release cycle, I don't want
>(nor need) to dictate how to do it, but I want to be able to adjust
>myself as best as possible with what was intended by the team.
>
>Regards,
>Fred.
>
>On 09/14, Björn-Egil Dahlberg wrote:
>> 2014-09-14 1:27 GMT+02:00 Dan Gudmundsson <dgud@REDACTED>:
>>
>> > On Sat, Sep 13, 2014 at 9:32 PM, Tristan Sloughter <t@REDACTED>
>> > wrote:
>> >
>> >>  Wait, so 17.2 is internal but 17.3 is external?
>> >>
>> >
>> > On Sun, Sep 14, 2014 at 12:02 AM, Fred Hebert <mononcqc@REDACTED>
>>wrote:
>> >
>> >>
>> >> So is this to say that the 3 minor releases could as well be 17.1,
>>17.3,
>> >> 17.199 ? Is there any regularity we can expect in version numbers,
>>or we
>> >> just won't really be able to know?
>> >>
>> >
>> The error here was to use numbered services releases and also tie them
>>to a
>> system version.
>>
>> Actually there are two errors. System versions shouldn't so closely
>> resemble semvers since they
>> might cause confusion. The reasoning behind it has been laid out in
>> previous mail discussions.
>>
>> I view a system version, i.e. 17.0, 17.2, 17.2.2, etc, as a set of
>> application versions,much like
>> versions of OS distributions with preinstalled programs. Any pattern
>> in the system version naming should be viewed by you as purely
>>coincidental
>> ..
>>
>> Perhaps it would be better to name service releases like Erlang/OTP -
>>2014
>> September.
>>
>> Or just name the releases after random authors or book titles to keep
>>you
>> guessing =)
>
>> _______________________________________________
>> 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/20140914/f06ed77b/attachment.htm>