[note: moderator moved this post to new thread. It was in response to the following]
Makes total sense.
I know this has been discussed, but I can’t find a cohesive description of the official release strategy. This is important for people who are teaching classes, convincing coauthors to start using Julia, planning the design of new packages, planning what material to teach in classes, figuring out when/how to publicize Julia, etc. Can I summarize what I think I have heard (without dates, which are of second-order importance):
- Alpha release of 0.7 as soon as the backlog of PRs is complete, with emphasis on stabilized APIs and pushing forward all breaking changes. Performance is secondary if it doesn’t break APIs. Question: Am I, a non-insider, supposed to install this and work with it for simple things, or wait? (e.g. will there be a JuliaPro?)
- Beta releases of 0.7, which is hopefully solid enough to do development on (has a JuliaPro installation, etc.)? Questions: at this point, should we publicize that it is time to update and/or write new packages? Should I be using Pkg3?
- A little bit of time (1-2 months?) to allow package developers to port packages. Maybe arm-twisting of critical packages that would need to be ported before the media descends. e.g. Plots, DataFrames, DifferentialEquations, JuMP, Distributions, etc.
- Release of 0.7 and 1.0 simultaneously? This is where I am most unclear. Question: at this point, I should tell everyone to start using it, or should I wait for tooling to catchup?
Now, if something like that is indeed the plan, it sounds pretty good, and it would be useful for an official communication. But there is a tension: you want package developers and power-users to know that Julia has stabilized, and that it is time to go all-in on the language. But you don’t necessarily want to have a deluge of typical users if the experience isn’t quite there, or key packages are not yet ported.
To resolve this tension, what about the following (which may be the strategy, I just can’t figure it out from the discussion):
- Have the 0.7 officially released as soon as possible, as you discuss (perhaps even without waiting for a porting period for packages beyond what is required to find 0.7 bugs). Then you can publicize to package developers, IDE embedders, etc. that the julia language itself is now stable and to be used and that everything written would work with 1.0.
- Let the package developers port things over, and get the development environments/precompilation/workflow as responsive as possible in the meantime (i.e. don’t even think of calling something 1.0 without a debugger supporting breakpoints, better to add 45 minutes of precompiling in the JuliaPro installation than 2 minutes of a key library post-installation, and hack a plot solution for the tutorials that doesn’t take 2 minutes before the first plot) Once the key list of packages are ported, and the Juno/VS Code experience seems sufficiently responsive, then release a 1.0 with confetti, balloons, and without having to avoid the press.
- I agree wholeheartedly to avoid worrying about runtime performance issues during this whole process. Post 0.7 and pre-1.0, though, it is probably worth dealing with low-hanging fruit in the “perceived” performance issues for a typical JuliaPro installation.
If this is the plan, then great. If not, then please reconsider a simultaneous 0.7 and 1.0 release.