<div dir="ltr"><div>I think it is perfectly possible to keep the old functions in the same 'string' module in a clean way if you just reorganise the documentation. Now all the functions, both the new and the obsolete, are kept in one alphabetical list which makes it difficult to see which are which and get a clear overview of the functions. Why not just separate the functions into 2 groups, the new and the obsolete, each in its own alphabetical list? This would make it easy to keep the old functions while making it easy for people to choose the newer ones, and migrate code if desired. There would then be no need to get rid of the old functions and break backward compatibility.<br><br></div>Robert<br><br></div><div class="gmail_extra"><br><div class="gmail_quote">On 25 November 2017 at 15:10, Jesper Louis Andersen <span dir="ltr"><<a href="mailto:jesper.louis.andersen@gmail.com" target="_blank">jesper.louis.andersen@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I think the only way to approach a problem like this is by asking:<div><br></div><div>"How much are you willing to spend on your backwards compatibility?"</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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</div><div><br></div><div>* Cannot use a new function when it is introduced. That would break backwards compatibility.</div><div>* Cannot use functions which have been removed. That would break forwards compatibility.</div><div><br></div><div>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.</div><div><br></div><div><br></div></div><div class="HOEnZb"><div class="h5"><br><div class="gmail_quote"><div dir="ltr">On Sat, Nov 25, 2017 at 2:50 AM <<a href="mailto:ok@cs.otago.ac.nz" target="_blank">ok@cs.otago.ac.nz</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">A couple of years ago I was working through a Java book.<br>
Not one of the examples got a clean compile.  Not one.<br>
oddly enough, it was string-handling functions that had<br>
been deprecated, and oddly enough, in my environment the<br>
old functions still did everything I needed.<br>
<br>
It's not just Erlang and Java.  I had C code using some of<br>
the classic string functions in ways I had carefully ensured<br>
were correct.  Porting to the next version of the Unix<br>
flavour I was using, the linker screamed at me about unsafe<br>
functions.  Since I wanted other people to use the program<br>
and didn't want them looking down on me, I spent a merry<br>
couple of hours changing the code to use memcpy instead of<br>
strcpy and so on.<br>
<br>
Again, I have a program which works fine in Solaris 10, Open<br>
Solaris, and Solaris 11 Express.  It uses a mix of old<br>
functions (hey, if the code still works, why change it, am I<br>
right?) and new functions (if you can call POSIX 2008 "new".)<br>
But OpenIndiana?  I am still baffled as to what combination of<br>
feature test macros I can set to make the program compile, and<br>
am coming to the conclusion that there isn't one.<br>
<br>
Did I mention the trouble I've been having with Ubuntu 17.10?<br>
I'll spare you that, but let's just say that putting standard<br>
headers in nonstandard places really really does not help.<br>
<br>
I don't really have a solution.  It seems as though the only<br>
thing you can do to ensure that old code continues to work is<br>
to keep a VM imagine with a complete copy of the environment<br>
it used to work in.<br>
<br>
Good luck plugging new libraries into that, though.<br>
<br>
<br>
<br>
______________________________<wbr>_________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/<wbr>listinfo/erlang-questions</a><br>
</blockquote></div>
</div></div><br>______________________________<wbr>_________________<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" rel="noreferrer" target="_blank">http://erlang.org/mailman/<wbr>listinfo/erlang-questions</a><br>
<br></blockquote></div><br></div>