Open orso82 opened 3 months ago
@bclyons12 looks like QED.jl is already been used: https://gitlab.com/hzdr/qedjl-project/QED-jl
QEDbase, QEDcore, QEDprocesses are actively developed and registered on the General registry, though QED itself is not registered on the General registry https://github.com/JuliaRegistries/General/tree/master/Q
From their documentation, it looks like their strategy there is to rely on a mix of their own registry and the general one
My alternative suggestions:
I'd fight for FUSE.jl
After discussing this further @bclyons12 and I decided that the best approach is to keep our FuseRegistry
. This will allow us to:
This said, we will still want to register in the General registry some key packages that we'll want people to use independently of FUSE to build applications that are FUSE-compatible. This means:
Let's start with renaming IMASdd
and registering those to the General registry. We can then consider doing this for other packages too, but the reality is that FuseRegistry
won't go away.
Possible renames:
IMASDD.jl
has now been renamed as IMASdd.jl
and is waiting to be registered on the General registry with CoordinateConventions
and SimulationParameters
(there's a 3 days grace period for new packages to get merged) 🎉
Next step is now to
FXP.jl
to FuseExchangeProtocol.jl
FuseExchangeProtocol.jl
to the General registryFuseUtils.jl
to the General registryMillerExtendedHarmonic.jl
to the General registry.Once that's done we'll then be able to register IMAS.jl
(and try to argue to keep that name).
IMAS
├─ CoordinateConventions
├─ FXP
├─ FuseUtils
├─ IMASdd
└─ MillerExtendedHarmonic
Ok, I think we're happy where we are now.
We should now wait 3 days, and then make a push to register also IMAS.jl
https://juliaregistries.github.io/RegistryCI.jl/stable/guidelines/