Good to know that development will continue
I’ve got an open PR. Should I migrate this myself?
Yes it will have a new name and be public very soon 
@jlapeyre yes porting the PR to the new repo will help a great deal
17 Likes
In my opinion you forfeit the right to make decisions about a package’s name and future once you transfer it to an org, then leave that org yourself. The whole purpose of orgs is to ensure that open source contributions to the julia ecosystem outlast the engagement of its original authors.
Regardless, I think this is an example of just this mechanism working, in Matt and James taking steps to ensure the long-term persistence of the package in the ecosystem - incredibly important for a package with a whopping 184 direct dependents.
46 Likes
Rebranding is a small thing if it allows us to be the bigger person eh… community.
9 Likes
The JuliaGraphs organization is happy to announce that the development of graph algorithms and analytics software in Julia will continue for the foreseeable future. We have managed the disruption of the archiving of LightGraphs.jl by reclaiming the old Graphs.jl package and have released Graphs.jl at v 1.4.0 using the final version of LightGraphs which was v1.3.5. Graphs.jl is now the official home of JuliaGraphs Development.
The following packages have also been renamed to match Graphs.jl
- LightGraphsExtras.jl → GraphsExtras.jl
- LightGraphsMatchings.jl → GraphsMatchings.jl
- LightGraphsFlows.jl → GraphsFlows.jl
You can track Graphs.jl adoption on JuliaHub
We have brought on additional organization members including Huda Nassar (@nassarhuda), Guillame Dalle (@gdalle), and Moritz Schauer (@mschauer). Huda has brought in the MatrixNetworks.jl package for linear algebra approaches to graph analysis into the JuliaGraphs organization. Updates to the JuliaGraphs packages that depend on LightGraphs are ongoing. If you have issues on any archived repo that you would like addressed, please migrate them. We are grateful to everyone who has stepped up to bring their skills and efforts to the JuliaGraphs ecosystem.
71 Likes
1.4.0
Impressive you managed to make that a non-breaking update.
6 Likes
awesome news!
2 Likes
It is very much a breaking update. The previous version of the Graphs package was 0.10.3.
6 Likes
Well, it’s simultaneously very breaking and not breaking much at all, depending upon your perspective. Since the LightGraphs history is preserved inside Graphs.jl, you can see that pretty much all the code changes are for the module names and documentation and CI. Jumping from LightGraphs to Graphs shouldn’t be very difficult at all (but is technically a “breaking” upgrade since it requires some code changes to do so). Jumping from Graphs v0.10 to v1.4 would of course be a complete re-implementation.
9 Likes
I thought the number was chosen to be the next up from Graphs’ last number. But I see, Graphs 1.4.0 is the feature release following LightGraphs 1.3.5, with the new feature of being named Graphs 
This is good, I’m just being facetious.
3 Likes
I have already transitioned one of my packages and I can confirm that the transition is way easy. All I needed to do to get it working with Graphs was to change the Project.toml dependency from LightGraphs to Graphs and switch using LightGraphs to using Graphs.
However, from a semantic versioning point of view this is more than technically breaking. Trying to use a graph from LightGraphs with functions from Graphs doesn’t work at all (*) and my package was documented to take a LightGraphs graph as input. I worked around that with a horrible hack but I expect that a lot of packages really will break user code with the transition.
(*) More specifically, this is what happens:
julia> import LightGraphs, Graphs
julia> graph = LightGraphs.path_digraph(5)
{5, 4} directed simple Int64 graph
julia> Graphs.outneighbors(graph, 1)
ERROR: method outneighbors not implemented.
Stacktrace:
[1] _NI(m::String)
@ Graphs ~/.julia/packages/Graphs/mjncd/src/interface.jl:16
[2] outneighbors(x::LightGraphs.SimpleGraphs.SimpleDiGraph{Int64}, v::Int64)
@ Graphs ~/.julia/packages/Graphs/mjncd/src/interface.jl:320
[3] top-level scope
@ REPL[3]:1
There is nothing strange or surprising about this but it is breaking in a real sense.
9 Likes
thank you so much for your efforts. my research group heavily depends/ed on LightGraphs.jl.
4 Likes
Will code depending on the old Graphs.jl work with the new one? Soss depends on that rather than LightGraphs. At least at the time it was much easier to use for non-Int nodes, and my graphs are mostly relatively small. But if that’s being deprecated (is it?) I’ll need to find a transition path.
I think the old Graphs.jl has been effectively abandoned for a long time. In fact, the old Graphs.jl was archived in the JuliaAttic github group. Actually, it’s still in the Attic, but now called OldGraphs.jl:
2 Likes
Thanks @CameronBieganek. Docs on JuliaHub give me a 404, so two questions…
- Does the new Graphs.jl have a topological sort?
- Does the SimpleGraphs module have anything to do with the SimpleGraphs package? Oh wait, or maybe that was in the old Graphs. Sorry, this is confusing me.
Yup:
https://juliagraphs.org/Graphs.jl/dev/pathing/#Graphs.topological_sort_by_dfs
Nope, the SimpleGraphs module is unrelated to SimpleGraphs.jl.
SimpleGraph and SimpleDiGraph are the two provided implementations of the AbstractGraph API from LightGraphs (now Graphs).
2 Likes
Yes, all old versions of Graphs are still there and work the same as before. The two repos have been merged and hah can think of Graphs 1.4 as a very breaking new release of the old Graphs that happens to have the same API as LightGraphs 1.3.5, aside from the package name.
3 Likes
Nice! Guess I need to swap out UUID and version numbers, and maybe it’s all good to go
You shouldn’t have to do anything if you’re using an older version of Graphs. You may have to add a compat entry to make sure it doesn’t get upgraded to 1.4 which has the new LightGraphs API.