# About Julia's development policy regarding Windows

**URL:** <https://discourse.julialang.org/t/about-julias-development-policy-regarding-windows/128011>\
**Category:** General Usage\
**Tags:** windows\
**Created:** [April 12, 2025, 7:29pm UTC](https://discourse.julialang.org/t/about-julias-development-policy-regarding-windows/128011 "2025-04-12T19:29:51Z")\
**Posts on this page:** 1\
**Showing post:** 60

<div class="post-metadata">

**Author:** ![mbauman](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mbauman/32/31082_2.png) [@mbauman](https://discourse.julialang.org/u/mbauman)\
**Post date:** [April 16, 2025, 2:43pm UTC](https://discourse.julialang.org/t/about-julias-development-policy-regarding-windows/128011/60 "2025-04-16T14:43:55Z")

</div>

The release process for patch (1.2.x) releases is slightly different than that for minor releases (1.y.0). The former are _wayyy_ more conservative in what they include; everything must be straightforward bug-fixes. Patch releases are meant to be completely unobtrusive. They’re released much more frequently to help everyone avoid **known and fixed** bugs. Concretely, this means that the 1.11.6 patch release should not introduce any new regressions over 1.11.5; it’s no longer being compared against 1.10. Yes, it often fixes regressions over 1.10, but the time to find new regressions — and block releases — is in the much slower beta/rc cycle for the minor release. Once folks are using a particular minor release, it’s very much a good thing to get fixed bugs out as quickly as possible.

You keep talking about a checklist. There are multiple visible “checklists”: CI, PkgEval, backports PRs, issue labels, and milestones. The hardest part, though, is making sure the right line-items appear on them. But this is where open source can shine. There are multiple ways to make issues appear on one of those checklists, even without any special permissions:

- Add tests to Julia and the packages you use! Testing current working functionality is a great way to get involved in the process and broken tests are the absolute best way to ensure attention.
- Help review the 4k+ open issues on Julia itself, particularly the ones that are missing labels or haven’t been touched in a while. Make sure they have MWEs and still reproduce, and you can kindly ask for attention, too.
- Help bubble-up issues from the 10k registered packages to a JuliaLang/julia issue if it’s likely a problem in Julia itself. Everyone will have their own definition of what the most “core” or “fundamental” packages are; if a package you care about has a regression from 1.10 to 1.11, it’s _probably_ better placed as a Julia issue. Open one! Link to the package issue and try to minimize the problem as best you can.
- Pop in on a release branch in preparation and ask if some issue in Julia or the ecosystem should be blocking.
- Test the ongoing v1.12 beta, report issues, and help ensure they’re categorized correctly! Now’s the best time 🙂

I’m sorry this was so frustrating for you. And I get it; burned time really stinks.

---

_[View the full topic](https://discourse.julialang.org/t/about-julias-development-policy-regarding-windows/128011)._