[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.
I don’t understand (but it is not any problem for me) why this is split off from this topic. It is precisely what that topic is about and what I was trying to say as possibility to consider
Alpha release are for the package developers to start upgrading packages. It will be chaos. Don’t use it unless you have a good reason to (i.e. are testing an upgrading a package).
Yes, give things a try in the beta stage and open issues to Julia and packages so we can find out what we did wrong when upgrading.
Hopefully that’s the beta stage. But there’s always a few leftover bugs.
v0.7 is exactly the same as v1.0, except everything that is changed will throw deprecation warnings telling package authors how to update their code. Think about them as the same release instead of two different versions.
In general, yes this is the plan from what I’ve read and discussed, except for the extra “package time”.
The split of this comment makes no sense to me. @jlperla shared his point that is on-topic and was removed out from the thread. Can someone explain the rationale here?
I understand they are essentially the same, but why do they need to be “released” at the same time if the general tooling is not ready? There is only one shot to call it v1.0, and it is a marketing event - like it or not. You want to keep matlab users away from the current tooling and environment at all costs, or they will try to plot a graph in Juno, Control-C on minute 2 of the pre-compilation, and just wait for v2.0.
Precompilation isn’t going to change in a 1.x. If anything, it might get a little longer and get a little more comprehensive. But the package manager tells you it’s compiling everything? Are you just looking for precompilation on package install?
I am not suggesting any particular feature, griping about the state of precompilation, or even griping about the state of the tooling. Everything is moving in the right direction.
What I am saying is that the “experience” for the baseline JuliaPro installation should be much better before you label something v1.0. This can be done through a mix of things (e.g. making sure the debugger is implemented and stable, maybe having Revise.jl as an option in the JuliaPro installation which would add in the appropriate .juliarc.jl file, pre-compiling all of the packages on JuliaPro installation instead of on first-use, choosing a faster first-time-to-plot library as the default one used in tutorials, etc.). None of this has to do with the interface freeze everyone wants and at which point we could publicize the stability of Julia, but all of these kinds of things should be considered prior to publicizing v1.0 when relatively non-technical users will try the language.
We need the feature freeze to both get the developers who are working on Julia v1.0 to fix things around the ecosystem (for example, the debugger is almost entirely Keno yet he’s busy of course on Julia 1.0 things), and we need 1.0 to attract developers into the ecosystem. Marketing needs to be handled appropriately of course to ensure people know the current state, but I’m not sure it’s really that obvious that delaying 1.0 is a good marketing move.
Exactly. Hence my suggestion to release the v0.7 feature and interface freeze, and then buy some room to fill in the ecosystem holes, and then release v.1.0 with the appropriate fanfare.
For context: I am teaching courses with 20 undergrads and another with 20 grad students in 2 weeks and am insisting they use Julia 0.6 for the projects. I decided yesterday to do a fresh JuliaPro installation to walk through the setup instructions I had written down, and add any steps required from download until displaying the first plot in Juno. It was enlightening, and I suggest anyone trying to think through the experience of a Matlab user deciding to try v.1.0 upon release do this walk-through.
Anyways, my point is made so no need to repeat it.
These are two very different things, that should be separated: You do not need a version 1.0 to stabilize the language for Julia developers working on packages. Just announcing that there will be no breaking changes after e.g. 0.7, should be enough: Julia developers are already following the language.
v1.0 is indeed a big opportunity to attract new developers (and coming from a dying language, I assure you you want to). However, if newcomers experience a errors, incompatibilities and (extreme) slowness on their first tries with the language (following basic tutorials, small tests), you will lose them (likely forever). Furthermore a number of them will publish their experience on blogs, etc., scaring even more people from even trying.
If delaying 1.0 is needed to make sure the many first time users get a smooth experience with 1.0, I think it is a vital marketing move. You should be able to have tutorials demonstrating basic scientific computing that just work (no errors, incompatibilities, …) properly (no minutes waiting just to make a graph). So there would need to be at least one compatible/just works package for graphs, statistics, dataframes, …
It would be nice if something like these “approved” tutorials were available with the release of 1.0.
It would also be good if the startup/first use slowness problem could be solved generically before 1.0 (or maybe even before 0.7, are we certain it can be solved without breaking changes?), if only to stop many of the “I tried this so-called fast Julia language, but it is actually slower than $MYCURRENTLANGUAGE” blogs/messages.
I can sympathize with this view, but extrapolating from the pace of previous developments, this could literally take years to achieve.
Your points are valid and there is obviously a trade-off here. Julia is not as polished at this stage in every respect as some alternatives, but provides benefits that outweigh the inconvenience for a specific set of users. It is just important to focus on this group and manage expectations realistically. I assume that the core team thought about this, and I trust their judgment; after all, they have the highest stake in the language.
The discussion here is largely premised on the psychological significance of “1.0”. However, I should remind people that version numbers have a purely technical meaning according to the Semantic Versioning scheme that is followed by Julia and many other free/open-source projects: it is a technical guarantee of backward-compatibility for all 1.x releases. Version numbers like 0.7 or 0.8 don’t make this guarantee.
When 1.0 is released, this point should be made very clearly: Julia 1.0 means that you can build Julia programs without worrying that they will be full of deprecations or breakage a year later. At the same time, we should make it clear that major usability improvements (e.g. in ahead-of-time compilation) are still planned for 1.1 and later releases.
This has been probably said already but I think it’s worth repeating: a large use case of Julia is, I believe, user-developers, i.e. people who, had they been using say Python or R or Matlab or Octave wouldn’t really have been able to turn their research ideas into a numerical library (as this library would have had to be written in C++, Cython or something similar). In Julia instead the transition from user to package developer is a natural and easy step. For this class of people, having Julia 1.0 is a huge relief.
Users who don’t really need any of Julia unique features will probably still prefer more established frameworks due to lack of polish in the Julia package ecosystem. The only thing we can do to improve that is to make concrete PRs to improve usability (add the option to recompile all stale caches after an update, if Gadfly takes too long at startup, also recommend packages with faster start up time on Julia pro etc).
For those who are concerned about Julia: I think it is instructive to study other successful open source languages that target (more or less) the same audience. In particular, the early history of R, from 1993 (initial announcement of the project) to the 1.0.0 release in 2000. Looking at their NEWS.0, they were struggling with similar issues, some of which were fixed later on in the 1.* releases, with plenty of issues remaining for later releases. The plotting capabilities, now considered gold standard, came later: eg ggplot2 was started in 2005.
My impression is that R was wildly successful not because it was just a bit better than the other n competing languages in the same niche, but because it was (1) providing something new that was (2) eagerly awaited by the audience (3) so much that they were willing to put up with a bit of inconvenience. I expect that the same applies to Julia.
Yes. That is exactly right. The people screaming don’t call the environment v1.0 yet! are not saying a bunch of new features are needed in the language.
The typical matlab (or even fortran) user does not understand semantic versioning, and relying on this technicality is a surefire way to alienate non-package developers.
Moreover, anyone considering writing a package probably does understand semantic versioning. The corrolary is that they will also understand completely if you publicize v0.7 as being identical to the v1.0 of the language (with deprecations) and that they don’t need to wait for an official v1.0 marketing release.
I have seen three types of posts (and likes of posts) on 1.0 from 3 different groups;
1. Julia Insiders and Package Developers: They want a feature freeze and release of the APIs as soon as possible, with no more non-breaking additions to the language prior to a widespread release. The goal is to make sure people know it is the right time to write packages. I agree entirely.
2. Julia Users who are Terrified of a Disasterous v1.0 Release Those who want the language stabilized, but are on the front-lines of getting Matlab and Fotran users to start using Julia, and want the basic installation and “experience” to be good enough prior to publicizing the version 1.0. Note that none of this has to do with the language per-se.
3. Julia Users who think Particular or More Features need to be added prior to Release: These posts include worries about comparing matlab vs. julia performance for some particular task, the lack of a fast implementation of Hilibert matrices containing rationals, etc.
As far as I am concerned, the group 3 should be pushed off. Features in the language or libraries is not helpful prior to a release.
But the goals of group 1 and 2 are entirely compatible. Have a complete feature freeze on the language itself, release v0.7 as soon as possible, and then whenever you can get the JuliaPro installation to feel faster as an experience (and have the Juno/Gallium up to date) release v1.0 as soon as possible. None of this has anything to do with the language. We can’t submit PRs for JuliaPro installation, and there aren’t any missing issues for Juno and Gallium and Pkg3 you don’t already know. Things are all moving in the right direction, you just need more time to tweak JuliaPro after you stop working on Julia itself.
But in the mad rush to a joint v.7 and v1.0 release, you will notice that there doesn’t seem to be A SINGLE user of group 2 on the message boards who thinks you want to publicize the current environment as v1.0. I suggest taking that as a huge hint that could be a huge public relations disaster. You may think of the Julia the environment and Julia the language as separate, but none of the users do.
Moreover, it would be a completely avoidable and an unforced error. There is huge risk in prematurely calling something v1.0, and almost nothing to gain. Package developers will understand the nuance of a v0.7 release prior to a v1.0 release and can start coding. The group 2 users are not asking for particular features, griping about compilation times, or anything. All they are saying is: freeze the language ASAP, and get the environment/tutorials/etc. in a good enough state prior to publicizing something as v1.0
Maybe to keep everyone happy, call it v1.0.0-beta for a bit? Seems arbitrary though. There will be an alpha/beta-phase, but when the language itself is well-tested for release, keep it there a bit longer for the environment? Seems weird but if it makes people happy…
Well put. This is exactly the plan. The JuliaPro team has already been working on Pkg3 integration for months, which fixes a ton of the problems with the distribution. The reason that 1.0 does not need to be released later than 0.7 is that there is a fair amount of lead time for tooling work while we go from 0.7-alpha to 0.7 final/1.0.
Is there a plan for more lead time? Last I read from you it stated that it would follow like other releases, hoping for a shorter alpha phase than v0.6.
