immutable dependencies

[jfirebaugh]

We had several days of build instability in mapbox-gl-native and mapbox-gl-js due to unexpected changes in upstream mason dependencies. In some cases the problem was that a mason branch was deleted while projects still used it, in other cases it was that the build script changed in ways that broke certain platforms. What's common to both cases is that they revealed an architectural weakness in how we manage dependencies with mason: there's no way to test or stage changes to packages without potentially breaking downstream projects.

This is closely related to an architecture invariant that I think every package system comes to adopt (or regret not adopting) at some point: once published, a particular version of a package should never change, period. Being able to overwrite binaries or install scripts for a particular version is just asking for trouble -- namely, uncontrollable breakage of downstream projects.

Let's consider:

• Uploading build / install scripts to S3 along with binaries, so there's no direct dependency on particular git repositories or branches being available.
• Suffixing the package version number with a monotonically increasing "build" number, e.g. mesa-10.4.3-1, mesa-10.4.3-2.
• Requiring that dependencies be specified by package version and build number.
• Never overwriting a package-build version on S3.

This would ensure that we can safely iterate on packages in mason without risking uncontrollable downstream breakage, and downstream packages get reproducible builds and the assurance that dependencies won't change out from underneath them.

[ljbade]

@jfirebaugh what about package version + git hash in configure? Then we can keep an archive of build script + binaries on s3 for each hash?

Suffixing package version will result in an explosion of mason branches.

[jfirebaugh]

Suffixing package version will result in an explosion of mason branches.

I was envisioning keeping the same branch naming conventions and incrementing a build number stored somewhere else. Using a hash (or short hash like mesa-10.4.3-a36df3) has the advantage that Travis could autogenerate it, but the disadvantage that you can't quickly tell which version is more recent.

[ljbade]

@jfirebaugh Perhaps tags are better method for capturing package releases, perhaps those can have a version appeneded

[mikemorris]

I'd be :+1: on an implementation using tags, as it keeps versions a bit more visible than stashing old packages on S3. Whichever way we implement this though, it would be great to fully build this out as a mason feature. Something like:

• mason install mesa 10.4.3 install latest tag and pin to that tag somehow
• mason install mesa 10.4.3 --tag=v1.0.0 install a specific tag (verbose to avoid confusion with package version)
• mason tags mesa 10.4.3 list published tags for a mason package (maybe with a * next to currently installed tag if applicable)

[jfirebaugh]

We now have immutability for mason core and script.sh's via pinning a mason submodule to an exact git hash. This has improved downstream stability. What we are still missing is immutable binaries. My opinion is that once a binary has been published, we should assume that any change to it could potentially break downstream packages, and refrain from modifying it. To implement this policy:

• Mason should not allow you to overwrite published binaries on S3
• We should never do so manually
• We should have an alternative versioning mechanism to handle packaging changes within the lifetime of a single upstream versioned release. As discussed above, this could be a suffix with a monotonically increasing "build" number or a git short hash.