Release process: Make binary packages available for beta and rc when they are released, to facilitate testing external packages

[mkoeppe]

Several "external packages" (i.e., python/cython packages depending on sage) now use Travis CI, a mainstream automated testing facility. A sample project that does that is available here:

• https://github.com/mkoeppe/sage_sample

Because of the time limits imposed by Travis CI, it is not possible to build Sage from source for such a test. Therefore, binary releases are used.

I propose that the release process be changed to make binaries available for beta and rc versions, to facilitate testing of external code to be compatible with such prerelease versions. (For Travis CI, only one build, linux/64bit/sage-$VERSION-Ubuntu_12.04-x86_64.tar.bz2, is necessary.)

Depends on #33131

CC: @sagetrac-tmonteil @mmasdeu @mforets @jdemeyer @vbraun @dimpase @slel @culler @NathanDunfield

Component: build

Keywords: days84

Reviewer: Dima Pasechnik

Issue created by migration from https://trac.sagemath.org/ticket/22657

[vbraun]

comment:1

What do you want to test? Afaik the free TravisCI account time limit (1 core for 1h) is way too short to run the Sage testsuite.

[mkoeppe]

comment:2

The goal is to test the test suite of an external package - such as the linked "sage_sample".

But I could also imagine other tests that are directly relevant for Sage -- such as testing that in the binary release, compiling works; that each optional package can be installed into the binary release; etc.

[dimpase]

comment:3

I suppose we can also consider paying for TravisCI from a grant.

[mkoeppe]

comment:4

Replying to @dimpase:

I suppose we can also consider paying for TravisCI from a grant.

The point of this ticket is to enable users to use mainstream, freely available testing infrastructure. I do not propose to change the Sage project's testing infrastructure.

[mforets]

comment:5

I cannot help in the technical work, but count me in for testing purposes. The sage_sample template is already well documented, but if needed I could help in that direction too.

At the risk of stating the obvious: in some academic communities (example), the possibility to unit test your own or your peers code with little effort, has a potentially high impact.

[mkoeppe]

comment:6

Replying to @mkoeppe:

But I could also imagine other tests that are directly relevant for Sage -- such as testing that in the binary release, compiling works; that each optional package can be installed into the binary release; etc.

I've created a testing package that does that at https://github.com/mkoeppe/sage_binary_tester
(see test results at https://travis-ci.org/mkoeppe/sage_binary_tester). These are limited tests (and the scripts needs some work -- there's something going on with font-cache warnings), but for example the testing on the different Mac OS X versions that Travis CI provides could perhaps be valuable.

[mkoeppe]

comment:10

Volker, I'm bumping this up to critical to suggest to run the binary building scripts for the next rc so that people can test whether the built binaries work. This would be a helpful improvement of the release process - in particular in light of the unresolved issue #31565, which is likely to affect the binary build, and other tickets such as #31562 that also have the potential for that; and of the various issues that the 9.2 binary had (#31131, #30556, sagemath/binary-pkg#28).

[mkoeppe]

comment:11

Having a binary distribution of an rc for macOS would probably also be helpful for the developers of the next-generation Mac App.

[mkoeppe]

comment:12

Moving to 9.4, as 9.3 has been released.

[mkoeppe]

comment:15

This never happened or even received a reaction from whoever builds the binaries, and better options (conda) are now available. So we can close it as outdated

[mkoeppe]

Dependencies: #33131

[dimpase]

Reviewer: Dima Pasechnik