3 ms·

Alternatively, you may see this as a sign that we've thought carefully about which APIs are stable enough to be part of the long term stability guarantees of 1.

Alternatively, you may see this as a sign that we've thought carefully about which APIs are stable enough to be part of the long term stability guarantees of 1.0, and which APIs are not, making it more likely that we'll able to maintain those guarantees longer. Also, there nothing really special about code that used to be in base, but is now in stdlib other than historical accident. It so happened that we used to ship a git client as part of the language, but the HTTP client was a separate package, despite the latter probably being a lot more useful to users. Packages can and do have their own stability guarantees. With the language itself maturing, I imagine package authors will start taking advantage of this more.

newen 8y ago
Yes I get your viewpoint about long term stability guarantees and feel it's valid to a certain degree. But I waiting for so many years for Julia 1.0 while expecting the entire language (base + stdlib) to have API stability for at least a few years, and hopefully many many years, like Fortran or at least Matlab. Also, I wish you guys would have some overarching philosophy w.r.t API stability in the stdlib. From looking at the github, it seems like the core developers are just delegating API change decisions in the standard library to new people who are not as familiar with the code base, without much discussion at all. I just don't think that is the way the stdlib should be managed.