On Fri, Sep 20, 2024 at 05:29:41PM +0200, Simon Tournier wrote: > Hi Ludo, > > On lun., 16 sept. 2024 at 11:47, Ludovic Courtès wrote: > > > I would hope we can migrate straight to 1.9, but if that’s too tricky, I > > agree we should follow the plan you describe. > > > > Let me take a look at those failure to see how bad it is. > > I would suggest to have julia-next. > > And some ’package-with-julia’ transformation similar as > package-with-python or package-with-ocaml. > > Somehow, that’s always painful to upgrade Julia because of the Julia > world rebuild and some (more than some?) package breakages. > > That way it would easier to have the CI following the branch team-julia > where regular package would go, as well as julia-next upgrade. And the > manifest could build both set of packages (julia and julia-next) using > the transformation. > > Users willing stable just install ’julia’ and ’julia-’ packages. > Adventurous users install ’julia-next’ and ’julia-*-next’. > > WDYT? The problem is that the julia-build-system needs to be adapted to the newer versions of Julia. IMO the benefit of having Julia and Julia-next is that the julia-* packages are packaged, but those needing a newer version of Julia can still get it from Guix. Then when we adapt the julia-build-system we can deprecate julia-next, or have it point to the next release. -- Efraim Flashner רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted