Julia 1.8, 1.9 (rapid release?)

General Usage
1

First, Julia 1.8.0 is a great release! 1.8.1 expected, but given @ViralBShah’s quote:

Given that 1.7 is not too far away (timed releases going forward)

when will 1.9.0-DEV be ready? It was already in dev “6 months ago” and I use master mostly, so what would happen if 1.9 was released about right away? It doesn’t seem too soon to release it as at least a beta, if not an RC.

I’m not trying to put more burden on the core developers (or users), but want to survey users: how frequent releases would you want or tolerate? Java does a release every 3 months, and for the Linux kernel, “Release Early, Release Often” means a new kernel every other month or so.

3. Avoid the Pressure of Larger Releases

When software releases contain lots of changes, developed over a longer period, there are more demands on a team. Longer periods between releases add pressure to make each release significant, with multiple large features.

More important than how quickly new releases of Julia are issued, is what to put into the next one. I’ve seen demands on Reddit, paraphrasing, “Julia developers should just focus on latency and drop doing anything else” (or was it AOT?). Open source doesn’t work that way, people work on what they like and/or what paid to do.

I still think each new release should have at least one major selling-point, e.g. latency for the next one (not commit to a release e.g. every 3 months otherwise). I could foresee a user survey on what one feature they want to delay (or not delay for anything) a release for.

I would want to get this one in before 1.9 (faster parser, but also better error messages, at least into the sysimage, could be off-by default, it can be installed separately though, so please try it):

Already in Julia 1.9 NEWS, notable:

  • The known quadratic behavior of type inference is now fixed and inference uses less memory in general. […]
  • The --threads command-line option now accepts auto|N[,auto|M] where M specifies the number of interactive threads to create (auto currently means 1) ([#42302]).
  • New option --heap-size-hint=<size> gives a memory hint for triggering greedy garbage collection.

Others very notable? And my own, that I was hoping would have made 1.8 months ago, when we thought 1.8 was imminent " --math-mode=fast is now a no-op". Since it’s a dangerous option, I propose backporting that PR to 1.8.1 if 1.9 isn’t released soon and 1.8.1 just skipped…

There are many open PRs on the GC (or parallel GC), not sure if this or other most relevant: [rfc] parallel marking by d-netto · Pull Request #45639 · JuliaLang/julia · GitHub or: GC mark-loop rewrite by d-netto · Pull Request #45608 · JuliaLang/julia · GitHub

@chflood’s PRs are interesting, she’s also doing good work on the GC, some already in, e.g.: Set high water mark for GC at 70% of available memory and only then start performing old generation gcs.

1 Like
2

I would personally suggest writing shorter post that are focused on one idea. Posts like this comes off as a bit rambly and it is hard to have a focused discussion.

Regarding:

That’s not how things work. Julia releases are time based and the work that is put in during that time period is what ends up in the release. They are not delayed based on some user survey.

21 Likes
3

I dropped point B. and C., and could maybe aggressively shorten more. I suppose I didn’t explain well.

Well, Julia 1.8 had a due date 15 February and it got overrun, then the due date was simply dropped. And as I stated, in some sense, 1.6 is already six-month old, so I’m curious when and who decides when ready and what should go into it a new release, and deemed stable.

4

We cut a release candidate on a time basis, but we can’t actually release until all the bugs are ironed out. Our standard for that is that PkgEval doesn’t show any breakage, and none gets reported to us for a week after a release candidate comes out.

16 Likes
5

When? I mean I know rc1 was 28 May, but could it have been much earlier, and what goes into deciding it? It felt more feature-based than time-based. It’s only obvious to me when a new DEV cycle starts, June 9, 2021 for 1.8-DEV (and the dropped due date) and 6 months ago for 1.9-DEV. Maybe more users are happy to use master like me, and not waiting for new features.

I very familiar with the good work Kristoffer is doing (and PkgEval), and you. Is there something in the development process that can be improved, instead of fixing the bugs, drop unbaked features and release more often?

Would it help to have an aggressively smaller Julia (e.g. without LinearAlgegra) for that? I probably didn’t connect the dots too well in my original post, but I could see a bare minimum JuliaLite, with nothing in Base other than what Julia needs for itself, where e.g. bugs or new features in GC needs to be worked out. That could be the latest released release (or sysimage), and wouldn’t need PkgEvel on all packages (or need to support them). Then the next oldest version could be full. I don’t think there’s yet a way to have a sysimage and another add-on sysimage, but planned?

6

Gosh, I’m very confused here. Do you want more frequent time-based releases? Or do you want each release to have a “selling point” feature? Do you want 1.9 to release now? Or with all those PRs you link merged? Even when calling for faster and more rigid time-boxed releases, there’s still that temptation to ensure your favorite features make it in.

This is the documented process. Yes, it says 4 months between feature freezes, and, yes, we’ve been averaging closer to six or eight. It probably would be good for the core team to start figuring out and announcing a freeze date for 1.9. But you know what? Baking a release is a lot of work. And even if 1.9 branched immediately, there’s still a thorough testing process to go through; it still may be months to a release.

You can use 1.9 right now — and it seems you do — on the development branch. It doesn’t have the rigorous testing of a release, but neither would a “rapid release.”

19 Likes
7

I don’t want 1.9 right now, just to know how soon, realistically possible. It’s not about 1.9 per se, I want to know how much we can, and want to, compress the schedule in general, say down to every six months (Java does a release every 3 months).

The following is an outline of the sequence of events surrounding a x.y.0 minor release:

  • Development (4 months)
    […]
  • Stabilization (1-4 months)

Julia 1.9 should already be in stabilization?

If I’m reading this right, then 5-8 months of development for each release, and we’re at 8 months on average since 1.5. Could we do, if we wanted to:

  • Development (2 months)
    […]
  • Stabilization (1-2 months)

Julia 1.9 may already have a “selling-point feature”, I’m fishing for what others want as such, pointing out interesting work done, that’s maybe worth waiting for or not.

Is that true or a myth? Are those proposing “Release Early, Release Often (RERO)” sacrificing testing/quality? Isn’t the testing/PkgEval automated anyway? And you expect less breakage with half the schedule (and I guess features then).

8

Are pre-existing bugs intended to be included in this policy?

9

pre-existing bugs are complicated. In general, if a pre-existing bug is found and it’s fixable easily we’ll backport it, but if a bug is found that isn’t easily fixable and is in previous releases, it may not be a release blocker.

5 Likes
10

The process of running PkgEval is automated. The process of reading the PkgEval results and analyzing them is manual and is very time-intensive.

8 Likes
11

Note that this isn’t necessarily fully true. It would be a highly appreciated (but large) chunk of work to provide better automation of knowing which parts of package eval failures might be real and which are likely random noise.

1 Like
12

Heh, no matter how often the team releases, I have my own schedule for “acceptance” – which is a minimum of six months and typically about 1 year. If a bug fix comes out for a bug that is affecting me, I would upgrade right away.

Time based releases every 4 months fit well into my acceptance model. Time based releases are a known technique to make incremental progress. If you wait for the “next big thing” you never release. It’s better to have a train schedule; if the “next big thing” misses the next train, there will always be another.

3 Likes
13

I have notebooks that does some of that, https://github.com/KristofferC/PkgEvalAnalysis/blob/master/analysis_18.ipynb.

4 Likes
14

As users who are not deeply involved in the release process, I think we have to be careful about making demands about the release schedule. It’s entirely possible that a 4 month release was aimed for, but it was reasonably judged that since 1.7 was delayed as well, if 1.8 was to be out on time, there would have to be an immediate feature freeze after 1.7, which would cause the 1.8 release to be feature-anemic. It’s a tough balance.

As a user, I must say I kind of welcome a longer release cycle, if it means a longer period of finding and fixing bugs such that the 1.x.0 release is more stable. Or - what if the actual process of releasing a version consumes to much dev time it takes away from development of new features? I mean, switching Julia versions 3 times a year is quite a lot. Of course, in the best of all worlds, we would have bug-free releases, on schedule every 4 months packed to the brim with features. But in the real world, we have to prioritise.

18 Likes
15

It turns out we need 1.8.1 for bugfixes (unlike that non-essential PR of mine), for e.g. this bug, but I had an idea for a Bugfig.jl (or Hotfix.jl?), explained there:

When I think about it, maybe all of Base (or a lot of it… and LinearAlgera.jl etc.) could be provided the same we to decouple the release schedule of the standard-lib from core Julia (what I

I’m not doing that, just suggesting/discussing the release process. It felt like 1.8 was delayed (due date cancelled), and I’m blaming no one, just thinking if/how the process can be improved, and if 1.9 is then delayed as much. Some of the work on releases is overlapping, for other languages, e.g. Python by design in PEP.

1 Like
16

As I’ve said before:

The blog post I linked above discussed how the time after a feature freeze is intentionally variable. v1.8 hit feature freeze in February. Everything after that was in the stabilization phase. This release just took a long time to stabilize.

We’ll do patch releases on v1.8 as needed until v1.9 is released.

4 Likes
18

There’s actually some good take aways here.

Big fixes would be nice to release faster but there’s some important manual work to ensure there are unexpected breaking changes to packages. If we want this automated someone needs to improve this situation but for the time being core devs are working on stuff that is more pressing. Maybe others could contribute here with some hard work?

There’s been previous discussion about improving transparency and structure around feature development but someone needs to make a fully thought out proposal for this. Drafting this and negotiating opinions for this is not trivial so if someone sees it as necessary they might want to consider starting such an effort now because it’s likely to take a long time to agree on.

Release times are very much considered an estimation right now. This may improve in the future but right now it shouldn’t be depended on for product development with a tight window.

2 Likes