Closed rayegun closed 3 years ago
CC: @ViralBShah
Thanks I did not realize that it had its own upstream repo. In that case we should separate it out from S/SuiteSparse
and into G/GraphBLAS
. @Wimmerer Can you do that and switch it to tracking the upstream repo?
I wouldn't worry about the version number. I doubt anybody has used it much. Let's use the upstream version number. If we receive too many complaints we can adopt 6.x I suppose.
@ViralBShah I will put in a PR yeah. I'll put it in G/GraphBLAS, that may eventually be an issue - it's the reference but not sole implementation of the GraphBLAS standard - but it should be fine for the foreseeable future. The other implementations I'm aware of use different names.
Yeah it occurred to me too. We can always do SSGraphBLAS if we want to leave the generic name open. My thought was that if that's the name Tim has chosen and others are picking different names, we should stick with the upstream name. If Tim changes it in the future, we can always adopt the change.
I'll ping @drtimothyaldendavis here, just in case he has thoughts.
SuiteSparse is 5.8 but that doesn't mean is newer than SuiteSparse:GraphBLAS, which is current v4.0.x. SuiteSparse is a meta-package, a package of packages, with its own version numbering (5.8 currently). That version number has nothing to do with the internal versions of each package it contains, although when I update the packages inside SuiteSparse, I bump the SuiteSparse v5.8 to 5.9, etc. The latest stable SuiteSparse:GraphBLAS is always in https://github.com/DrTimothyAldenDavis/GraphBLAS and then later on I update the version of GraphBLAS at https://github.com/DrTimothyAldenDavis/SuiteSparse .
Regarding the name: yes, "GraphBLAS" is generic, and can apply to other implementations of the GraphBLAS C API Specification. Calling my implementation just "GraphBLAS" is like calling the Intel MKL "the BLAS", or calling OpenBLAS as "the BLAS". I would leave the generic name open.
I call my package SuiteSparse:GraphBLAS, or SS:GrB for short.
Is SSGraphBLAS an acceptable name for everyone?
Yes, let's go with that.
That works great for me.
On Wed, Mar 3, 2021 at 2:11 PM Viral B. Shah notifications@github.com wrote:
Yes, let's go with that.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/JuliaPackaging/Yggdrasil/issues/2478#issuecomment-790022984, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEYIIOIGSNGE5CHL543BM4TTB2JV3ANCNFSM4W3NXJFQ .
@giordano
I can't recall which you preferred. We've got these options:
If we go with option 1, I would recommend putting it in S/SuiteSparse.
I've updated SuiteSparse to v5.9.0, and it now includes the latest stable GraphBLAS, v4.0.3. See https://github.com/DrTimothyAldenDavis/SuiteSparse/releases/tag/v5.9.0 .
So now they are in sync. Both of these: https://github.com/DrTimothyAldenDavis/SuiteSparse https://github.com/DrTimothyAldenDavis/GraphBLAS now have the same GraphBLAS v4.0.3, in their stable releases.
On Wed, Mar 3, 2021 at 4:00 PM Viral B. Shah notifications@github.com wrote:
If we go with option 1, I would recommend putting it in S/SuiteSparse.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/JuliaPackaging/Yggdrasil/issues/2478#issuecomment-790091439, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEYIIOMGLCSYVXIASOUQ3KLTB2WQDANCNFSM4W3NXJFQ .
I agree with Viral that option 1 may be the cleanest one
I discussed this in the BinaryBuilder Slack, but thought I should open an issue before attempting to retarget the repo. Currently it targets github.com/DrTimothyAldenDavis/SuiteSparse/. This is mostly fine but leaves us behind the upstream repo https://github.com/DrTimothyAldenDavis/GraphBLAS.
It should be relatively easy to update, and I'll make a PR shortly, but the version number will end up out of sync with the actual binary. GraphBLAS itself is on ~v4.0, while SuiteSparse is ~v5.x. After the Slack conversation we settled on updating the artifact to v6.0. Does that seem sensible? We won't match the versioning of the base repository but we'll avoid conflicts and ensure the latest version isn't below the previous.