Jira is https://issues.apache.org/jira/browse/METRON-710.
Justin On Thu, Feb 9, 2017 at 2:58 PM, Matt Foley <ma...@apache.org> wrote: > The only reason not to go “backwards” is if someone is going to try to use > Ambari Upgrade to move from the 0.3.0 Mpack to this one. > > I THINK it’s unlikely this is a concern, so I’m okay with 0.3.1.0, but I > would change my opinion if someone says a real-world user in the field will > want to use Ambari Upgrade. > > A moot point, of course, if Ambari Upgrade is known to NOT work with this > (and the previous) Mpack. So if someone can definitively say that, that > would be good to know too. > > Cheers, > --Matt > > On 2/9/17, 11:53 AM, "David Lyle" <dlyle65...@gmail.com> wrote: > > I'm good with 0.3.1.0. > > -D... > > On Thu, Feb 9, 2017 at 2:36 PM, zeo...@gmail.com <zeo...@gmail.com> > wrote: > > > I agree with Casey regarding the version itself, but I'd be fine with > > somethign else if someone else has a convincing argument. > > > > Jon > > > > On Thu, Feb 9, 2017 at 2:12 PM Justin Leet <justinjl...@gmail.com> > wrote: > > > > I can pick this up once we have an agreement on the version number. > When > > we agree on that, I'll make a Jira and rev it. > > > > Justin > > > > On Thu, Feb 9, 2017 at 2:05 PM, Casey Stella <ceste...@gmail.com> > wrote: > > > > > I do agree that the MPack should be rev'd and a new RC should be > cut. Is > > > there a way to name the versioning of the management pack so that > it > > > indicates the oldest version of Metron that can be installed with > that > > > version? So, in this case, maybe 0.3.1.0? > > > > > > Also, I'm looking for volunteers to take this renaming JIRA once we > > decide > > > to do it. > > > > > > Casey > > > > > > On Thu, Feb 9, 2017 at 1:56 PM, David Lyle <dlyle65...@gmail.com> > wrote: > > > > > > > Good looking out, Jon! > > > > > > > > I would recommend against version matching it with Metron. In the > > future, > > > > the MPack will need to rev much less frequently than Metron, so > MPack > > rev > > > > x.x.x.x will install Metron y.y.y+. My read on the prior release > bits > > is > > > > that 0.3.0 is using MPack 1.0.0.0-SNAPSHOT, which is either an > error or > > > an > > > > indication that we didn't actually release the MPack as part of > 0.3.0 > > > > (which is my view), so if we agree it's ready, we can call this > one > > > 1.0.0.0 > > > > and cut a new RC with that change. > > > > > > > > I'd also support the following: > > > > > > > > Declare it "not ready" and leave it at 1.0.0.0-SNAPSHOT > > > > Decide 0.3.0 actually did contain MPack 1.0.0.0 and increment > this to > > > > 1.0.1.0. > > > > (I'm sure there are other ways as well) > > > > > > > > My (weak) preference is to simply call this one 1.0.0.0. > > > > > > > > > > > > -D... > > > > > > > > > > > > On Thu, Feb 9, 2017 at 1:43 PM, zeo...@gmail.com < > zeo...@gmail.com> > > > wrote: > > > > > > > > > So I was spinning up the 0.3.1-RC3 candidate on my bare metal > cluster > > > > today > > > > > and I noticed that when I generated the mpack it still had a > version > > of > > > > > 1.0.0.0. I double checked and made sure that the mpack > existed in > > the > > > > > 0.3.0 release > > > > > <https://github.com/apache/incubator-metron/tree/Metron_ > > > > > 0.3.0/metron-deployment> > > > > > and > > > > > that it was modified in between releases via the changelog. I > would > > > > > normally recommend that we modify the version to match with > Metron > > > > (0.3.1) > > > > > but that would be going backwards. Thoughts? > > > > > > > > > > Jon > > > > > -- > > > > > > > > > > Jon > > > > > > > > > > Sent from my mobile device > > > > > > > > > > > > > > > > -- > > > > Jon > > > > Sent from my mobile device > > > > > >
