[Oberon] Distribution practice; was http://cas.inf.ethz.ch/projects/a2 .

[Michael Schierl]

Hello Peter,


Am 05.11.2022 um 05:21 schrieb peter at easthope.ca:
> From:	Michael Schierl <schierlm at gmx.de>
> Date:	Fri, 4 Nov 2022 23:15:20 +0100
>> ... git's preferred workflow and store only sources and not binaries
>> in the repo.
>
> Günter released UnixAos at intervals of approximately 6 months.
> http://www.informatik.uni-bremen.de/~fld/UnixAos/
>
> Would a hybrid practice work? Sources in a repository.  Binaries
> posted on a server as warranted.  Tools and instructions allowing
> convenient production of binaries when required.

When setting up GitLab, one probably also sets up a CI workflow which
will compile every new revision of the main branch (and also pull
requests if they are allowed). Then all you need is zip these up for
each architecture and make a "nightly link" available where everyone can
get the latest binaries. If one needs older ones, they would need to
compile them themselves.

The only tricky part here is that the Fox compiler is compiled with
itself, and there is as far as I know no independent bootstrap path
available. But when the CI jobs are set up to first compile the compiler
with the bootstrap compiler and then use the new compiler to recompile
everything again, the bootstrap compiler only needs to get rebuilt when
it introduces an incompatible change that makes it impossible to
recompile the new compiler (or there is a severe bug that propagates
into the generated binaries). Updating the bootstrap compiler binaries
would still be a manual task, but everything else is automated - so
users can either use the bootstrap compiler to compile it themselves (if
they are on the platform where the bootstrap compiler runs) or pick some
nightly binaries and start from there.


Having independent binary releases may also be a good idea, but in my
opinion it is orthogonal to nightly buils. Binary releases provide some
trust that the released version has been vetted more than a random
source repository revision, and may be a starting point for new users (o
users who do not like to live on the bleeding edge) to not get
frustrated immediately. Just picking random revisions and building
releases from them (without actually testing them more than any nightly
build) will thwart these benefits, as there is some perceived trust that
is actually not there. But that are just my 2¢.


Regards,


Michael