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