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
>
