You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
* Run everything on 1.10
* Expand buildkite runner into matrix
* Also run integration and ext testing on LTS
* Try LTS
* Just write 1.10
* Julia version number in matrix
* Document support policy
* Document support policy
* Restrict Julia compat properly
* Fix DynamicPPL tests on 1.10
* Simplify gitignore
* Formatting
* Relax performance bounds on nnlib scatter
* Improve error message
* Fix a problem
* Fix error introduced in the last PR
* Fix coverage
* Fix coverage
* Fix LuxLib
* Prevent small union inlining
* use static if everywhere
* Revert previous change
* Patch the problem
* Run error printing
* Bump patch
At any given point in time, `Mooncake.jl` supports the current Long Term Support (LTS) release of Julia, and the latest release version of Julia 1.
4
+
Consequently, the versions of Julia which are officially supported by `Mooncake.jl` will change (almost) _immediately_ whenever a new Julia LTS version is declared, or a minor release of Julia is made.
5
+
6
+
For example, the LTS is 1.10 and the latest release is 1.11 at the time of writing. When 1.12 is released, we will
7
+
1. bump the Julia compat bounds in `Mooncake.jl` to require either 1.10 or 1.12,
8
+
1. cease to run CI on 1.11,
9
+
1. cease to provide bug fixes for 1.11,
10
+
1. cease to accept 1.11-specific bug fixes, as we will not be running CI for 1.11 and therefore will not be able to test that they have worked.
11
+
12
+
In short: as far as `Mooncake.jl`'s future releases, 1.11 ceases to exist the moment 1.12 is released.
13
+
14
+
Note that these changes are not applied retrospectively to existing releases of `Mooncake.jl`.
15
+
Suppose that `Mooncake.jl` is at `v0.4.50` when 1.12 is released.
16
+
Then the above changes would be relevant to `Mooncake.jl` versions `v0.4.51` and higher.
17
+
18
+
# Patch Versions
19
+
20
+
The above only discussed minor versions of Julia (1.10, 1.11, 1.12, etc).
21
+
However, it also applies to patch versions of Julia.
22
+
For example, at the time of writing, Julia version 1.10.6 is _actually_ the LTS, and 1.11.1 the current release of Julia.
23
+
The moment that 1.10.7 is released, we will cease to run any CI on 1.10.6, and will not accept fixes for it.
24
+
The same is true of 1.11.2.
25
+
26
+
Since patch releases of Julia are less invasive than minor releases, this should generally not cause users problems.
27
+
28
+
# Context
29
+
30
+
In order to support a particular version of Julia, we must
31
+
1. always run CI for that version,
32
+
1. accept and proactively produce fixes for that version,
33
+
1. maintain version-specific code in the `Mooncake.jl` codebase.
34
+
35
+
This requires a surprisingly amount of overhead to the development of `Mooncake.jl`, and has the potential to substantially increase the complexity of the codebase.
36
+
All of this makes it harder to improve `Mooncake.jl`.
37
+
Consequently, this policy represents a decision to tradeoff support for a range of minor Julia versions in exchange for easing the development burden associated to `Mooncake.jl`.
38
+
39
+
## Why not gently drop support?
40
+
41
+
In the JuliaGaussianProcesses ecosystem, we had a loosely-defined policy of keeping support for an older version until we ran into a large problem which could not be fixed easily, at which point we would drop support.
42
+
While this sounds appealing, in practice it makes it hard to know exactly when to drop support for a particular version of Julia, increases the burden for maintainers, and makes it hard for users to know exactly what to expect.
0 commit comments