[erlang-questions] Breaking backwards compatibility in Release 17.0-rc2
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.
More information about the erlang-questions