I think it's a really good idea. There is some complexity: a) Image releases do not map 1:1 with Metron releases and Atlas doesn't allow -SNAPSHOT in their release number scheme. That is, we'll have different versions of the image that work with a 0.4.1-SNAPSHOT Metron and some released versions of Metron that won't require a new image (A guy's gotta believe). I think that can be easily worked around.
b) If the Quick Dev image becomes one of our release artifacts, Atlas is likely the wrong place to host it. I always thought of Quick Dev as a developer tool, so our obligation is to make it work with the current master and any branches currently used by devs. I hadn't really reasoned about the notion of a "released" Quick Dev image, but I can see a lot of value in having a versioned sandbox type image- but maybe not quick dev, maybe not even Vagrant? We could actually pre-package everything needed and save some provisioning time on released versions. It'd just come up ready to go. I think, should we want one, we should release it as a convenience binary signed and hosted alongside the other release artifacts. Meantime, we could keep the incremental versions of Quick Dev in Atlas. Anyway, I think it's a really interesting notion. -D... On Mon, Apr 24, 2017 at 11:26 AM, Nick Allen <n...@nickallen.org> wrote: > Right now, we have the images that get pushed to Atlas for Quick Dev > <https://atlas.hashicorp.com/metron/boxes/quick_dev> versioned > independently from the rest of Metron. We currently have versions 0.1.0 > and 0.2.0. > > What happens when a user downloads an official release of Metron, like > 0.3.1, and attempts to run Quick Dev? I would assume that the code would > download the latest image version, which we may have been updated since the > release. This would cause it to fail for the release version. Am I wrong? > > If we had the Atlas images follow Metron's versioning scheme, would this > solve the problem? Are there other cons of doing this? > > Thanks >
