You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For the JLLs (GAP_pkg_*_jll) the pattern is to map GAP version 1.2.3 to 100.200.300, plus potentially an offset. This decouples the GAP version from the Julia version a bit and gives us room to update the wrapper packages even if the underlying GAP packages have not changed.
should we adopt a similar scheme for the wrappers here in this repository?
how to deal with package versions like 2021.04-03 (used by Homalg and CAP these days)?
in the past, some packages had versions like 1.0c. I don't think that is the case for anything right now, but perhaps the GAP side should start to impose tighter constraints on version patterns?
GAP packages don't follow semver, so we may need to take that into account, too..
The text was updated successfully, but these errors were encountered:
For the JLLs (
GAP_pkg_*_jll
) the pattern is to map GAP version1.2.3
to100.200.300
, plus potentially an offset. This decouples the GAP version from the Julia version a bit and gives us room to update the wrapper packages even if the underlying GAP packages have not changed.2021.04-03
(used by Homalg and CAP these days)?1.0c
. I don't think that is the case for anything right now, but perhaps the GAP side should start to impose tighter constraints on version patterns?The text was updated successfully, but these errors were encountered: