Oliver Schulz

> The tests now pass using julia-1.11, but are significantly slower. Let's see if we can reproduce (and then benchmark and investigate) this locally.

I'd like to pull this into the other major changes I'm working on - the resulting version of MeasureBase will require Julia v1.10 (designated as the next LTS), so we...

> I'm struggling a bit more with the second part of the proposal. Essentially, version compatibility would be improved because instead of a single DI version number that has all...

> Can you explain in concrete terms how this would have prevented e.g. #506 Not at all, it turns out, I should have used SciMLSensitivity instead of DiffEqSensitivity (which is...

> Can you give me a concrete combination where you don't get what you want? That would happen when you also (possibly indirectly) depends on a package that requires A=2...

> But this situation wouldn't be any different in the scenario you're proposing, right? Except that what the user gets are old versions of the DI backend subpackages Yes, but...

> So here the underlying assumption is that "algorithmic packages" (like SciML) need the latest DI to function well Not quite - I rather have the following situation in mind:...

> Since I'm not gonna go back in time and implement support for B=1, even with your proposal I don't see how B=1 could ever be possible in an environment...

> with the current configuration the user would just get an older version of (all of) DI, the last one before B=1 was dropped. How is that a problem? Because...

> And with your suggestion, we could fill all the remaining squares? Yes, I think so, as long as the DifferentiationInterface API has no breaking changes in between. But I...