[erlang-questions] Breaking backwards compatibility in Release 17.0-rc2

Loïc Hoguin essen@REDACTED
Fri Feb 28 22:46:03 CET 2014

On 02/28/2014 06:10 PM, Andrew Thompson wrote:
> What about simply having one major release where both are valid, then
> one release where it is deprecated and then after that remove it.  For
> projects which support the 'last two major versions', which seems to be
> the sanest way, that would allow them to migrate.

In theory it is a great solution. In practice it is meaningless, as it 
is not safe from errors from the OTP team. Unexpected incompatibilities 
or simply bugs may be (and are) introduced in any release.

The OTP team is already trying to avoid breaking things when possible 
(utf-8), but sometimes this is not possible (-callback), perhaps because 
it couldn't be planned long enough, and sometimes they unexpectedly 
introduce bugs (SSL ciphers).

There is no good solution, things will always break as long as they're 

Taking care of these errors is not much extra work either, because if 
you are saying you support R15B+, then you better test your project 
using all these supported releases one by one (throw in maint and master 
too, it helps seeing issues coming and prevent OTP from breaking your 
project as you can provide feedback or act upon it long before release).

I am using this small script, personally: 

In less than 10 minutes I know what works and what breaks across all 
supported versions. If I made the mistake of using binary_to_integer/1, 
then I see it immediately. If something changed in master and breaks my 
code, then I see it immediately too. (There still are some tests failing 
due to the utf-8 change, I haven't pushed the "fix" yet, for example.)

If I were to have a specific branch for a version of Erlang then I would 
just have to do a small modification to that script. When I add Windows 
support then same deal. I will probably end up with a 100-lines script 
to run tests across all supported platforms and versions, plus a 
20-lines script per R<X>B branch to convert the master code to code that 
works on that specific version of Erlang.

It's very manageable, and not only will I know for sure the code works 
fine on all versions, but I will also be able to deal with issues that 
may arise in OTP and either provide feedback quickly or fix it in my 
source in time for release.

As this is something that I am now doing across many of my projects, 
this is definitely something that may land in erlang.mk in the future.

Loïc Hoguin

More information about the erlang-questions mailing list