I am not sure about this, I hope there will be a 2.0 in the medium run.
While I appreciate the continuing improvements on master, I am concerned that the “last chance to fix things” mindset will either delay the release, or result in changes that get less testing than usual.
I am not sure either. But I suppose it is much more difficult to change a simple name as e.g. srand if everybody is being used to it. Maybe I’m naïve, but such simple commands I somehow expect to be stable after 1.0.
Kind of a dilemma: beta ‘promises’ (?) no more changes but reasonably important issues still surface.
The release is already delayed, proper testing would mean more delay, at this point I don’t think time matters anymore.
In the future Julia needs agile releases, shorter release cycles, at some point devs have to let a release go, as is, freeze → stabilize, and then reiterate.
That is just a misunderstanding, no one has made any promise about user facing stability, I also had the wrong expectations.
RCs are for when devs think it is finally ready (but still there won’t be any promise about no more breakage, if it’s in the name of stability, at that point neither).
So if you want a guarantee, wait for 1.x, breaking the stability promise at that point, would be outrageous, even if our definitions of stability are not the same, I don’t think anyone would dare to do that.
I’m under the impression that the stability promise only applies to Base: StdLib may have breaking changes. It looks like this change is in StdLib anyways…
Yes, you are right about that, this is only taking Base into account. So, do expect long release cycles and major breakage in the future, up til RCs (where you can expect minor breakage from then on) in all related release processes, and finally stability on point releases only.
The good thing is that release process is so long that we may at least have a long and stable Base for a while. 
While I appreciate what you are getting at.
The eve of RC1, is still the eve of RC1. As in it is before RC1.
the very reason beta2 was released and not RC1, was because it was not ready for RC – people didn’t have the confidence that nothing like this would be needed.
The time in which we stop – RC1, is the time in which we stop.
This is a bit of a tautology
I believe there were still new depreciations in 0.6-rc3, so even rc1 is not necessarily the end of breaking changes.
Beta software is beta software, doubly so if it’s 0.x-beta. I think by using beta software one is implicitly accepting that things might change. So it’s a bit odd to me that people voluntarily use beta software, then complain things are changed.
Wasn’it planned from the beginning that breaking changes will be had before the final 1.0 release? Things are just as they are intendended to be, and then they will be stable after. Seems like a good thing to me.
Wasn’it planned from the beginning that breaking changes will be had before the final 1.0 release?
No, it was planned that breaking changes caused by new features would’ve been had before the feature freeze, which was a while ago.
Things are just as they are intendended to be,
No, if they were, Julia 1.0 would have been out some months ago.
and then they will be stable after.
And when would you plan to spend time making sure they are stable? After the release?
How could you make sure if even on RCs there can be new breaking changes caused by new features (however small they may be), not caused just by bug fixes?
Seems like a good thing to me.
Seems bad to me, I expect lots of quick fixes during 1.x “stable” release, all the new breaking features, should have targeted 2.x.
If there are any bugs, and their fixes are breaking we will have to live with those bugs until 2.x
I mean, it’s not the end of the world, and 1.0 will go out with more and better implemented features (not properly tested by the community ecosystem as a whole), so I can understand why some developers and users are getting tired of it.
Dev → Freeze → Alpha → Beta → RCs → Release → Reiterate
In order to get from “free” development to a stable release, a stabilization period is needed in each release cycle.
This period is divided in many sub-phases (as much as needed), with the sole purpose of each next phase being more stable (feature wise) than the last one.
This stabilization is started by a feature freeze, after which, only bug fixes should be allowed, some fixes may cause breaking API changes, but still, any new features (specially the breaking ones) should continue being developed in development branches (for the next release (2.x)).
In this sense the Julia release cycle, even when meaning to use the same terminology and bending their semantics, is very atypical, sometimes very rushed, sometimes too lax, with little communication to users outside of core dev circles, and I’ll timing of announcements vs decisions.
I am not ungrateful, I really admire the work done on Julia and the devs.
I hope we can all learn of this first major release cycle, to time and communicate intentions better, and have more discipline in self imposed dead lines like feature freezes.
Yet I can not agree that things are just as they were intended to be, unless you think the 1.0 feature freeze and the 1.0 release will be the same event (because new features even if non breaking at RCs time means there is still not a proper feature freeze).
That being said I truly believe time doesn’t matter anymore, just take your time, to test everything properly, I hope many many RCs are released along the way, and that the last one won’t introduce any last minute minor breaking or non breaking features at all, just bug fixes.
Give people time to adapt, don’t play with their efforts and expectations, those are worth too! If you make any wrong decisions or announcements, learn to retract them (not apologize), don’t just go on with it and pretend it’s normal.
cf
In retrospect, I wonder if a v0.8 would have made sense before v1.0.
As far as I’m concerned, things are exactly as they are intended to be, with time and patience everything will fall into place. It is restlessness and agitation that is going to lead to shoddy results due to pre-mature decision points. In the grand scheme of things, a few minor deprecations are going to be forgotten, at least from my point of view. I’m happy there are people out there committed to finding issues and fixing them and getting it fixed for everyone. If there are a few more changes, it is a sign that there is productive activity happening, meaning that things are getting better. These are the intentions that I stand by, this is open source, so somebody is bound to be dissappointed, but I’m happy.
We’ll just have to agree to disagree. Things are exactly as they are, not as they were intended to be.
You say “a few more minor deprecations/changes”, I wonder how much more can still be considered “a few”. Also these minor changes add up!
For the release to happen, we need to stop making changes for that target at some point.
But I am glad you are happy!
With respect, I don’t perceive either in the community. Just some confusion about whether v0.7 is still a moving target. I welcome the improvements, but I also recognize the fact that some package developers would time their work on updates accordingly.
My reading of the v0.7 release cycle is the following:
For the language per se, v0.7 introduced truly fantastic features and compiler optimizations, and laid the groundwork for others. This allows a convenient redesign of some interfaces, which will probably be going on for a while.
In parallel, Pkg3 is coming. This, again is an important and very significant change for the package ecosystem.
It is mostly the same people are working on many of these things, which strains scarce resources.
I don’t think it would have been a good thing. I’m happy to see some more changes before 0.7 (especially this one, which makes tons of sense). A few more weeks are always going to be worth it if means a “better” 1.0.
More broadly, the upwards trajectory of everything in the language (looking back from 0.3) means that we can trust the core devs. I think the track record here speaks for itself.
I feel like that logical fallacy should have a name. If I trusted the upward trajectory of a company I would be super rich right now.
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.
When will 1.0 be available?
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 
.
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.