Hacker News Reader

Comment by KenoFischer | Hacker News Reader

To answer the usual complaint whenever the release announcement gets linked here, the NEWS file is intended to give current users of Julia an overview of all the things that changed that they may want to adjust to. It is however, not designed to give people who are only casually following the project an overview of all the work that's going on and why it's happening. We've been talking about writing a more casual document like that for the releases, since they do tend to get a fair bit of attention, but that's just one more thing on an already-extensive list of things that need to be done for each release.

View on HN

”It is however, not designed to give people who are only casually following the project an overview of all the work that's going on and why it's happening.

The NEWS file may not be designed for that, but IMO, it still is way better than this text, which, for casual followers, doesn’t say much more than “1.4 replaces 1.3, no breaking changes, a few new features”, without even mentioning those features, or why they were added.

Maybe, combining the two in a single document, and copy-pasting NEWS.md in the announcement, would decrease the amount of work and improve things?

I dunno, the comments were pretty informative.

Looks like Julia still haven't managed to handle updates well.

I remember being so amazed that they'd blown their 1.0 announcement (went from 0.7 to 1.0 over a Juliacon).

And because there were so many changes (most of which i thought were good), it was pretty broken for new users at that time, which I firmly believe limited their adoption.

And to be clear, I love the idea of Julia, and that first document made me fall in love. And I think that the design for statistical computing is really, really good.

It's just a shame that this ops/packaging stuff is holding them back.

The 0.7 to 1.0 was a planned move that was communicated for over a year. If anything, the 1.0 transition went very smoothly and the Julia community grew significantly soon after its release. All the download and community stats broadly demonstrate this.

IMO, 1.0 was rough not for new users but people who had invested a bunch of time in Julia codes pre 1.0. We anticipated this and therefore had a very carefully planned release strategy to ease the transition with depreciation warnings and preparing 0.7 as a migration aiding release for 0.6 users to 1.0. In fact our release announcement discussed all of this at great length.

https://julialang.org/blog/2018/08/one-point-zero/

> The 0.7 to 1.0 was a planned move that was communicated for over a year.

That sounds as if the communication was of the “1.0 will be released at this date one year in the future” kind. But it was more like saying for a year “it will be finished and released someday” and then, according to the wikipedia, “the release candidate for Julia 1.0 was released on 7 August 2018, and the final version a day later”.

Releasing at JuliaCon was always the communicated goal, though admittedly with a bit of a hedge that we may not manage to get it done. As for the 1.0RC business, 0.7 and 1.0 are the same release except that 0.7 includes additional depreciation earnings that are not in 1.0. This decision was made to keep with our communicated policy of having at least one versions where deprecations would produce a warning. There were a number of 0.7 release candidates in the months leading up to the release. Since the changes in 1.0 were minimal over 0.7, it didn't need extensive validation and the one day was enough to make sure it worked. Would a bit more time have been better? Sure, but in retrospect it was totally fine. 1.0 was a fairly solid release and has gotten more solid with the LTS patch releases that many people still use. The big problem was packages in the ecosystem needing 2-3 months to catch up, but I'm not sure that could have been avoided. One of the learnings we have is that most people won't upgrade their software until the new version is released and upgrading is absolutely necessary.

So, for me at least, the issue was that I downloaded 1.0 (having played with Julia in the past).

When I tried to install packages, I got errors after error as a result of deprecation warnings from 0.7 becoming errors at 1.0.

Again, I really like Julia, and want it to succeed. But the 1.0 situation put me massively off, and killed my plans to start evangelising Julia at my company.

It's just a shame, that's all.

> There were a number of 0.7 release candidates in the months leading up to the release.

Really?

v0.7.0-rc1 - Jul 31, 2018

v0.7.0-rc2 - Aug 2, 2018

v0.7.0-rc3 - Aug 7, 2018

v1.0.0-rc1 - Aug 7, 2018

v0.7.0 - Aug 8, 2018

v1.0.0 - Aug 9, 2018

https://github.com/JuliaLang/julia/releases

I really enjoy using Julia too but I have also been disappointed with how the updates have played out. Just a few weeks ago I rolled back my installation from v1.2 to the LTS version because of silly errors in the plotting package not allowing me to plot.

Otherwise it really is a pleasure to use, and I have found that the LTS install has zero compatibility issues thus far.

Glad to hear that the LTS version did not have an issue.

I hope you did file an issue with the Plots package. The reason is that we generally like to make sure that regressions like these are not language level regressions. Sometimes package use undocumented internals - but we generally chase each and every single one of these.

For those who haven't seen it yet, we have described our release process in great detail in this blog post: https://julialang.org/blog/2019/08/release-process/

It's natural that you'll get publicity and curious onlookers when doing new releases -- might be worth considering that natural audience, too, when writing the NEWS file.

Right, we're of course aware of that audience, which is why I posted that comment. The way the NEWS file gets written is just that each individual commit that makes a change that needs end user attention will add an entry in the relevant section. This is quite hand as people can just 'git blame' the file and automatically find a link to the relevant commit (or they can click through the linked issue). What's missing is a more high level narrative structure of changes in the release, but such a thing would have to be written once the release is done. Usually we do that in the form of a blog post announcing the release. However, invariably, these things end up on HN the second somebody thinks the release is done (or even just for early RCs).

Reply on news.ycombinator.com