Oops, very much not deprecated. It was moved to being a sub-library of OrdinaryDiffEq for easier maintenance. I’ll make sure the readme is updated to make this less confusing.
yeah, we definitely should have put out a PSA and updated the readme before moving the package. There shouldn’t be any downstream noticable changes. the package continues to exist and will continue to get updates etc. the only change is where it’s hosted (to make it easier to make changes that affect both diffeqbase and integrators at the same time)
The package is not deprecated, the code is just moved to Ordinarydiffeq.jl for maintenance purposes.
There is a very long DifferentialEquations.jl about this. Traveling so can’t find but a quick search will find it. And JuliaCon 2024/2025 both brought this up in the birds of feather discussions. But also, this is a maintainance question, since it’s not a functional change, so it’s really a question to maintainers what is easiest to do downstream testing while developing.
The PSA is the v7 blog post but v7 needs to merge first. The State of SciML 3 hour video and the v7 issue has a lot of detail of what is happening though. All of this is shared online starting 2 years ago.
But main thing, no downstream code needs to change if a GitHub repo is transferred to a new location. It’s strictly a permissions change for test and CI.
I understand there may have been earlier mentions of these plans, and I appreciate the work that goes into maintaining the ecosystem.
My concern is less about whether it was mentioned somewhere previously, and more about whether changes affecting widely used foundational packages are communicated in a way that downstream users can realistically discover and respond to.
For changes with ecosystem impact, it would be helpful to have a formal public announcement closer to the transition date, clear migration guidance, and an open thread inviting community input from package maintainers and production users. That would likely reduce confusion, surface downstream constraints earlier, and strengthen trust between maintainers and users.
I’d also be interested in understanding how the package is being characterized as lightweight going forward. If it continues to influence dependency resolution, compat bounds, precompilation behavior, or remains tightly coupled to other parts of the ecosystem, then many downstream users may still experience it as carrying meaningful ecosystem weight even if the direct code footprint is small.
I’m raising this in the spirit of collaboration—I’d genuinely like to see the transition succeed with broad community participation.
I don’t understand your concern here. This change should have zero community impact and require no “migration”. You seem to be making a big deal out of what is a simple reorganization. Already the communication around this reorganization that was linked from this thread surpasses my expectations for what is necessary or appropriate. How did this change affect you?
For me, the impact was uncertainty rather than breakage. I maintain StanJulia packages with dependencies in this area, so seeing a historically important package archived/moved without an obvious contemporaneous notice raised practical questions:
Is this purely administrative, or should downstream maintainers expect future compat changes?
Where should issues or contributions now be directed?
Is there any recommended timeline for dependency updates?
Is this part of a broader restructuring that downstream packages should prepare for?
Now that clarification has been given, that helps.
My broader point is simply that communication is most useful when it is visible at the moment people encounter the change. It’s difficult for maintainers to recall or discover announcements made a couple of years earlier unless they are linked again through a README note, repository banner, registry notice, or similar reminder.
So I never meant this caused immediate damage—only that a short, visible notice saying “maintenance moved here; no downstream action required” would have answered those questions immediately.
Is that exactly true? A registry can update the URL for everyone who add/dev the package from there, but wouldn’t people who add/dev the package by an explicit URL and possible subdirectory be stuck in the archive until they manually switch to the new ones? There’s a good chance nobody installed DiffEqBase that way, but I’m wondering if that should be an explicit caveat of bypassing registries in general.
It is definitely a caveat of using URLs directly – not sure if it’s mentioned in any docs at the moment. Is this something that should be warned against e.g. here under “Adding unregistered packages”?
But I do feel like it’s clear that when installing a package using URLs that there is no implicit guarantee that the URL will keep working indefinitely. The registry faces the same problem when a package author suddenly decides to delete the project under the registered URL, so it’s not really only an issue of installing packages via URLs.
In the case of this package, the repo still exists on Github as “archive”, so installation via URL will still work, unless the repo will be completely removed at some point. So my understanding is that there is really no observable change for anyone, even when using the explicit URL to install the package.