Why are we even considering adding new deprecations like Rename srand to Random.seed! by MoonCoral · Pull Request #28295 · JuliaLang/julia · GitHub on the eve of rc1, weeks into the upgradathon and long after the beta release which explicitly said “now is a good time to get your packages ready for 0.7”? There’s something fundamentally wrong with the timing of this.
7 Likes
You have a point of course. But I much prefer if such occasional last-minute changes will be done still. After 1.0 it’s too late.
Also such a small syntax change (srand → Random.seed!) doesn’t seem problematic, one commit and your package is up-to-date again, no?
2 Likes
For your own package maybe. If you try to get your dependencies upgraded it involves other people finding time to review, commit, and release as well. As a case in point it took 17 days to guide a 0.7 compatible Libz into METADATA. After the srand rename it will keep working cleanly, but it will give a deprecation warning when running its tests and fail running its own tests once the deprecation is removed.
I’m not comfortable wasting other people’s time hunting a moving target. I will keep upgrading my own code as things change but fixing other packages will have to wait until final 0.7 is released.
1 Like
It does get a bit tedious when it’s not just one package but 20, and @GunnarFarneback makes good points regarding other people’s packages. I’m hoping the depwarns for this one will be mostly confined to test code though.
1 Like
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.
1 Like
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.
1 Like
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
8 Likes
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.
4 Likes
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.
1 Like
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.
2 Likes
cf
In retrospect, I wonder if a v0.8 would have made sense before v1.0.
2 Likes
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.
5 Likes
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!
1 Like
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.
6 Likes
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.
10 Likes
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.