` 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](https://github.com/JuliaLang/julia/pull/45639) or: [GC mark-loop rewrite by d-netto · Pull Request #45608 · JuliaLang/julia · GitHub](https://github.com/JuliaLang/julia/pull/45608)
@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.](https://github.com/JuliaLang/julia/pull/45442)
---
### Author:  [@kristoffer.carlsson](https://discourse.julialang.org/u/kristoffer.carlsson)
#### Post date: [August 18, 2022, 8:18pm UTC](https://discourse.julialang.org/t/julia-1-8-1-9-rapid-release/85949/2 "2022-08-18T20:18:42Z")
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:
> [@Palli](#):
>
> I still think each new release should have at least one major selling-point, e.g. latency for the next one (not commit to every e.g. 2 months otherwise). I could foresee a user survey on what one feature they want to delay (or not delay for anything) a release for.
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.
---
### Author:  [@Palli](https://discourse.julialang.org/u/Palli)
#### Post date: [August 18, 2022, 8:45pm UTC](https://discourse.julialang.org/t/julia-1-8-1-9-rapid-release/85949/3 "2022-08-18T20:45:40Z")
I dropped point B. and C., and could maybe aggressively shorten more. I suppose I didn’t explain well.
> [@kristoffer.carlsson](#):
>
> Julia releases are time based
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.
---
### Author:  [@Oscar\_Smith](https://discourse.julialang.org/u/Oscar_Smith)
#### Post date: [August 18, 2022, 8:54pm UTC](https://discourse.julialang.org/t/julia-1-8-1-9-rapid-release/85949/4 "2022-08-18T20:54:43Z")
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.
---
### Author:  [@Palli](https://discourse.julialang.org/u/Palli)
#### Post date: [August 18, 2022, 9:08pm UTC](https://discourse.julialang.org/t/julia-1-8-1-9-rapid-release/85949/5 "2022-08-18T21:08:47Z")
> [@Oscar\_Smith](#):
>
> We cut a release candidate on a time basis
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?
---
### Author:  [@mbauman](https://discourse.julialang.org/u/mbauman)
#### Post date: [August 18, 2022, 9:44pm UTC](https://discourse.julialang.org/t/julia-1-8-1-9-rapid-release/85949/6 "2022-08-18T21:44:52Z")
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.
> **[Julia’s Release Process](https://julialang.org/blog/2019/08/release-process/)**
>
> Julia’s Release Process | People involved in the day-to-day development of a project tend to become so familiar with its rhythm and process that they internalize it and it feels like everyone must just \_know\_ how each stage unfolds. Of course, from...
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.”
---
### Author:  [@Palli](https://discourse.julialang.org/u/Palli)
#### Post date: [August 18, 2022, 10:34pm UTC](https://discourse.julialang.org/t/julia-1-8-1-9-rapid-release/85949/7 "2022-08-18T22:34:57Z")
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.
> [@mbauman](#):
>
> It doesn’t have the rigorous testing of a release, but neither would a “rapid release.”
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).
---
### Author:  [@jar1](https://discourse.julialang.org/u/jar1)
#### Post date: [August 18, 2022, 11:58pm UTC](https://discourse.julialang.org/t/julia-1-8-1-9-rapid-release/85949/8 "2022-08-18T23:58:49Z")
> [@Oscar\_Smith](#):
>
> 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.
Are pre-existing bugs intended to be included in this policy?
---
### Author:  [@Oscar\_Smith](https://discourse.julialang.org/u/Oscar_Smith)
#### Post date: [August 19, 2022, 1:00am UTC](https://discourse.julialang.org/t/julia-1-8-1-9-rapid-release/85949/9 "2022-08-19T01:00:12Z")
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.
---
### Author:  [@dilumaluthge](https://discourse.julialang.org/u/dilumaluthge)
#### Post date: [August 19, 2022, 1:28am UTC](https://discourse.julialang.org/t/julia-1-8-1-9-rapid-release/85949/10 "2022-08-19T01:28:20Z")
> [@Palli](#):
>
> Isn’t the testing/PkgEval automated anyway?
The process of running PkgEval is automated. The process of reading the PkgEval results and analyzing them is manual and is very time-intensive.
---
### Author:  [@Oscar\_Smith](https://discourse.julialang.org/u/Oscar_Smith)
#### Post date: [August 19, 2022, 1:50am UTC](https://discourse.julialang.org/t/julia-1-8-1-9-rapid-release/85949/11 "2022-08-19T01:50:41Z")
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.
---
### Author:  [@blackeneth](https://discourse.julialang.org/u/blackeneth)
#### Post date: [August 19, 2022, 6:05am UTC](https://discourse.julialang.org/t/julia-1-8-1-9-rapid-release/85949/12 "2022-08-19T06:05:53Z")
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](https://signalvnoise.com/posts/3811-stuck-again) 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.
---
### Author:  [@kristoffer.carlsson](https://discourse.julialang.org/u/kristoffer.carlsson)
#### Post date: [August 19, 2022, 6:33am UTC](https://discourse.julialang.org/t/julia-1-8-1-9-rapid-release/85949/13 "2022-08-19T06:33:35Z")
> [@Oscar\_Smith](#):
>
> 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.
I have notebooks that does some of that, [https://github.com/KristofferC/PkgEvalAnalysis/blob/master/analysis\_18.ipynb](https://github.com/KristofferC/PkgEvalAnalysis/blob/master/analysis_18.ipynb).
---
### Author:  [@jakobnissen](https://discourse.julialang.org/u/jakobnissen)
#### Post date: [August 19, 2022, 8:03am UTC](https://discourse.julialang.org/t/julia-1-8-1-9-rapid-release/85949/14 "2022-08-19T08:03:53Z")
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.
---
### Author:  [@Palli](https://discourse.julialang.org/u/Palli)
#### Post date: [August 19, 2022, 5:57pm UTC](https://discourse.julialang.org/t/julia-1-8-1-9-rapid-release/85949/15 "2022-08-19T17:57:00Z")
> [@Palli](#):
>
> backporting that PR to 1.8.1 if 1.9 isn’t released soon and 1.8.1 just skipped…
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:
> [@Julia 1.8.0: 10.0^-Inf = NaN](https://discourse.julialang.org/t/julia-1-8-0-10-0-inf-nan/86004/5):
>
> Ouch, we need tests for the tests (and tests for the tests-tests…). FYI: For a hotfix if you can’t wait for 1.8.1 (and don’t want to downgrade): julia\> import Base:^, @constprop julia\> @constprop :aggressive function ^(x::Float64, y::Float64) xu = reinterpret(UInt64, x) xu == reinterpret(UInt64, 1.0) && return 1.0 # Exponents greater than this will always overflow or underflow. # Note that NaN can pass through this, but that will end up fine. …
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
> [@jakobnissen](#):
>
> making demands about the release schedule.
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.
---
### Author:  [@mbauman](https://discourse.julialang.org/u/mbauman)
#### Post date: [August 19, 2022, 6:11pm UTC](https://discourse.julialang.org/t/julia-1-8-1-9-rapid-release/85949/16 "2022-08-19T18:11:01Z")
> [@Palli](#):
>
> It felt like 1.8 was delayed (due date cancelled)
As I’ve said before:
> [@The future of Julia, 1.6, 1.7-rc1, 1.8, 1.9, 1.10 and 2.0 and LTS](https://discourse.julialang.org/t/the-future-of-julia-1-6-1-7-rc1-1-8-1-9-1-10-and-2-0-and-lts/68143/3):
>
> Don’t pay too much attention to GitHub milestones. They’re internal organizational tools, not external promises.
The blog post I linked above discussed how the time _after_ a feature freeze is _intentionally_ variable. v1.8 hit [feature freeze in February](https://github.com/JuliaLang/julia/commit/7b395153e80672f8cdb18f51dd653a85e28b2070). 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.
---
### Author:  [@Zach\_Christensen](https://discourse.julialang.org/u/Zach_Christensen)
#### Post date: [August 19, 2022, 6:46pm UTC](https://discourse.julialang.org/t/julia-1-8-1-9-rapid-release/85949/18 "2022-08-19T18:46:17Z")
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.