Historical tla2tools.jar rolling builds

[Andrew Helwer]

The most recent tla2tools.jar build can be downloaded from the github release, but is there any place to download the historical versions, perhaps organized by commit hash?

Andrew

[Markus Kuppe]

How far back do you want to go? Github [1] has releases dating back to 2014 (Toolbox 1.4.8), and the content of the directory `plugins/org.lamport.tlatools` in any of the Toolbox zip files, is identical to the content found in `tla2tools.jar`. If you need older than 2014, I've just shared [2] my private builds of `tla2tools.jar`.

There are git tags for all the version between 1.3.1 and 1.8.0.

Markus

[1] https://github.com/tlaplus/tlaplus/releases
[2] https://tla.msr-inria.inria.fr/kuppe/TLC/

[Andrew Helwer]

Primarily I'm interested in the build of every commit of main that is uploaded to the 1.8.0. rolling prerelease; are those archived anywhere or just overwritten?

Andrew

[Markus Kuppe]

We don't archive those builds currently. However, let's continue the discussion in a GitHub issue, if you believe archiving is necessary.

By the way, I've been using git bisect for finding regressions, in case that's what you’re after.

Markus

[Andrew Helwer]

This is motivated by my early musings about TLA+ release engineering, and learning nix for personal use. It would be nice to have reproducible builds for the TLA+ tools and especially TLAPS, with transitive dependencies locked, and an easy way to specify all of that. Especially if we are using a rolling release model. Both Nix and Guix offer something of this sort. There's an interesting article in Nature about it through the lens of reproducible research (https://www.nature.com/articles/s41597-022-01720-9). Since TLA+ and TLAPS are used in research projects & papers, we should consider providing researchers an easy format to encode the exact versions their dependencies at the end of the paper, which other people can copy & paste to their local environment to reproduce their results indefinitely.

I'm not 100% sure that keeping all rolling builds around would be important for this purpose but it seems likely; more research is necessary on nix/guix packaging and what free build artifact caches exist.

Andrew