I may have missed a discuss thread on this, but it looks like we are no longer using -SNAPSHOT in our current dev master https://github.com/apache/incubator-metron/blob/master/pom.xml#L19
On Tue, Apr 25, 2017 at 12:34 PM, Nick Allen <n...@nickallen.org> wrote: > >> 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. > > I really like the idea. I think it would be very beneficial to have a > single pre-packaged image for each release that users can download and take > new features for a spin. > > If we do stick with Vagrant for this I think Atlas works just fine. Who > else is going to host a 5.1 GB image for us? :) Although I am very open to > alternative implementations of this idea. > > > >> 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. > > Would be interested to get other opinions on this. I am good with making > that assumption. Whatever the community agrees on for Quick Dev though, > we should document it as such. Right now, I think it would be reasonable > to assume that a user would download a release and expect to be able to > launch Quick Dev. > > > > > > > > > > On Mon, Apr 24, 2017 at 11:51 AM, David Lyle <dlyle65...@gmail.com> wrote: > > > 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 > > > > > >
