[erlang-questions] Strings - deprecated functions

[Jesper Louis Andersen]

I think the only way to approach a problem like this is by asking:

"How much are you willing to spend on your backwards compatibility?"

Maintaining a long-term-release of a piece of software is no easy feat. It
requires effort, and that requires money. If you need stability from an
older release and you need control of that release, you have to give the
right people some money.

In Solaris, Sun had the advantage that they could use the Zone construction
in the OS. You could brand a zone, such that inside the zone, the Solaris
(10) system operates as if it were a Solaris 8 or 9 system. This is
achieved by manipulating the syscall table of the kernel and handling some
syscalls differently. Maintenance of such a compat layer is time-consuming,
however. In FreeBSD, you have libcompat for much the same thing: It
provides you with a way to run legacy binaries on a new system for a while,
so you don't have to upgrade all of your software in one go.

In Android development, the system runs by "API levels" (corresponding
somewhat to Erlang/OTP major releases). A given library functionality is
*introduced* at some API level, *deprecated* at a higher level and
eventually *removed* in an even higher API level. This means that any
function is alive over a "window" from introduction to removal.

In practice, one has to cope with changes of a system over time. What is a
problem is the rate-of-change, not the change itself. Historically, Erlang
is a fairly slow-changing system I think. My older Haskell code rarely
compiles, and the recent changes in OCaml also requires far more
interaction to make things work again on some code bases.

The changes are likely to require library maintainers to handle several
releases and this is where the hard part of the work is. A single project
can target a single Erlang release. A library, which may have to span
several Erlang releases

* Cannot use a new function when it is introduced. That would break
backwards compatibility.
* Cannot use functions which have been removed. That would break forwards
compatibility.

How large a deprecation window can be depends largely on factors such as
"how common is the function, and how easy is it to change the code?", "Do
we have a sponsor who wishes the older versions kept around, paying us to
do so?", and so on. You may quickly find it is cheaper for you to upgrade
the Erlang/OTP release rather than maintaining and older version of it.



On Sat, Nov 25, 2017 at 2:50 AM <ok@REDACTED> wrote:

> A couple of years ago I was working through a Java book.
> Not one of the examples got a clean compile.  Not one.
> oddly enough, it was string-handling functions that had
> been deprecated, and oddly enough, in my environment the
> old functions still did everything I needed.
>
> It's not just Erlang and Java.  I had C code using some of
> the classic string functions in ways I had carefully ensured
> were correct.  Porting to the next version of the Unix
> flavour I was using, the linker screamed at me about unsafe
> functions.  Since I wanted other people to use the program
> and didn't want them looking down on me, I spent a merry
> couple of hours changing the code to use memcpy instead of
> strcpy and so on.
>
> Again, I have a program which works fine in Solaris 10, Open
> Solaris, and Solaris 11 Express.  It uses a mix of old
> functions (hey, if the code still works, why change it, am I
> right?) and new functions (if you can call POSIX 2008 "new".)
> But OpenIndiana?  I am still baffled as to what combination of
> feature test macros I can set to make the program compile, and
> am coming to the conclusion that there isn't one.
>
> Did I mention the trouble I've been having with Ubuntu 17.10?
> I'll spare you that, but let's just say that putting standard
> headers in nonstandard places really really does not help.
>
> I don't really have a solution.  It seems as though the only
> thing you can do to ensure that old code continues to work is
> to keep a VM imagine with a complete copy of the environment
> it used to work in.
>
> Good luck plugging new libraries into that, though.
>
>
>
> _______________________________________________
> 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/20171125/09371652/attachment.htm>