Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support using GAP releases instead of branch snapshots #24

Open
fingolfin opened this issue Apr 21, 2021 · 2 comments
Open

Support using GAP releases instead of branch snapshots #24

fingolfin opened this issue Apr 21, 2021 · 2 comments

Comments

@fingolfin
Copy link
Member

Right now, we install GAP always from git; to test against e.g. 4.10, we use the stable-4.10 branch.

But it would be useful to (also?) be able to test against actual releases, such as 4.10.2 or 4.9.3. One important difference is that GAPInfo.Version is set correctly there (in git build, it is always 4.dev or something like that, which means version checks in code don't work).

Ideally, the user would be able to either specify "4.10" (and then gets whatever the latest 4.10.x is) or even a specific version like "4.10.2" (however, this later point is less important).

@olexandr-konovalov

This comment was marked as off-topic.

@fingolfin
Copy link
Member Author

Doing this shouldn't be too hard either:

  • add an alternate input to GAPBRANCH, say version
  • accept values of the form X.Y or X.Y.Z for them
  • the former (X.Y) is automatically mapped to X.Y.ZZZ the version of the latest release of the X.Y release series
    • for this we can just hardcode a list in this repo, and update the repo / this action when there are new releases
  • the Clone GAP step then is changed to say Get GAP sources and we download GAP from the appropriate place (i.e., for all new enough releases from https://github.com/gap-system/gap/releases/download/vX.Y.Z/gap-X.Y.Z.tar.gz -- actually, we could retroactively provide these for 4.9.x and 4.10.x, too (I don't think it makes sense to try to support older GAP versions for this)

That should be most of it.

Of course if we were to switch to docker images (see also issue #16) this may become moot, but unless someone actively works on that, I don't see why we shouldn't try the above (or a variation thereof)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants