> ## `ruby:<version>`
>
> This is the defacto image. If you are unsure about what your needs are, you probably want to use this one. It is designed to be used both as a throw away container (mount your source code and start the container to start your app), as well as the base to build other images off of.
>
> Some of these tags may have names like buster or stretch in them. These are the suite code names for releases of [Debian](https://wiki.debian.org/DebianReleases) and indicate which release the image is based on. If your image needs to install any additional packages beyond what comes with the image, you'll likely want to specify one of these explicitly to minimize breakage when there are new releases of Debian.
>
> This tag is based off of [`buildpack-deps`](https://hub.docker.com/_/buildpack-deps/). `buildpack-deps` is designed for the average user of Docker who has many images on their system. It, by design, has a large number of extremely common Debian packages. This reduces the number of packages that images that derive from it need to install, thus reducing the overall size of all images on your system.
This also changes the `buildpack-deps` detection so that it only triggers the "this image is large with lots of packages" description if some tag of the image being described is `FROM buildpack-deps` (and _not_ simply `-curl` or `-scm` variants), which adjusts `golang`, `haxe`, `influxdb`, `kapacitor`, `openjdk`, and `telegraf` to correctly have the shorter non-`buildpack-deps`-referencing description.
This uses the combination of us pushing to a namespace + `BASHBREW_ARCH` being set to determine whether we're pushing to an arch-specific page and should thus appropriately filter all content to the current architecture.
Joe Ferguson