Enough deprecations!

[ChrisRackauckas]

@vvjn

Regarding deprecations, I feel like the core team did a huge cop out when they decided to split off the standard library from base, and then guarantee no stability in the standard library. I was promised a stable julia base for 1.0 only to find out now that the stable julia base is now a small fraction of what was promised.

That’s one way to look at it, but that’s very superficial. The other way to look at it is, almost every bikesheding issue that would change surface syntax got a decision. Almost every single issue to directly syntax (change a name, change argument order, etc.) was looked at and got a PR or it was closed with the decision that Julia will not do that. So even if certain parts are less stable, all of those “we may change this” issues got there decisions and are done. Other things may change to add features, sure, but there’s a good commitment to the syntax now.

Also, packages can version the standard library, and each package can use different versions of their dependencies due to the local environments. So if there are changes you don’t want deal with for now, just upper bound. Your code base can upgrade when you feel like it and you can stay stable if that’s what you (or your business) needs.

[Yifan_Liu]

When will 1.0 be available?

[vvjn]

@ChrisRackauckas

Also, packages can version the standard library, and each package can use different versions of their dependencies due to the local environments. So if there are changes you don’t want deal with for now, just upper bound. Your code base can upgrade when you feel like it and you can stay stable if that’s what you (or your business) needs.

That’s actually really great to hear. I really don’t like having to update my code every few months (frankly, even every few years) just to fix up API changes in libraries. And yes I know, it’s a problem that’s everywhere in the programming world…but it’s clearly not a good thing.

[ChrisRackauckas]

@vvjn

That’s actually really great to hear. I really don’t like having to update my code every few months (frankly, even every few years) just to fix up API changes in libraries. And yes I know, it’s a problem that’s everywhere in the programming world…but it’s clearly not a good thing.

Pkg3 is supposed to fix this. If you’ve been upgrading code to v0.7 you’ll have noticed these environments. It was weird at first, but I think this “you can upper bound without effecting any other packages” is awesome after playing around with it. So I think the fix is .

[StefanKarpinski]

You will also be able to upgrade Julia Base and keep using older versions of stdlibs in the future. For example, if the LinearAlgebra version that ships with Julia 1.5 is incompatible with the previous edition of LinearAlgebra then it will have a higher major version number—say LinearAlgebra 2.0—and it may well be possible to use Julia 1.5 with LinearAlgebra 1.4. So the API stability is no lie: just upgrade Julia itself and keep the stdlibs you don’t want to deal with breaking changes in fixed. There will be some practical limits to how far we can allow compatibility mixing and matching to go, but since Julia itself will only be making non-breaking changes until 2.0, it should be fairly straightforward to keep older versions of stdlibs working with newer versions of Julia. This is one of the reasons we’ve been working so hard to make stdlibs as much like normal packages as possible.