Re: [DISCUSS] Metron next version rev

[Michael Miklavcic]

The question is if we actually need to back-port at all at this point. I
think the assertion here is that pretty much everyone using Metron right
now is currently getting patches, etc. by upgrading to the latest release.
If/when we find a need to fork release branches we can certainly do it and
have a more involved discussion pertinent to the circumstances at hand.

On Tue, Nov 15, 2016 at 10:17 AM, Otto Fowler 
wrote:

> Would the back ports also have to go through a full ‘apache release’
> process and be planned out as well?
> I don’t think that should all be worked out as we go.
>
>
> On November 15, 2016 at 12:13:55, Michael Miklavcic (
> michael.miklav...@gmail.com) wrote:
>
> I'm a +1 on David and Nick's suggestions. 1 and 2 now, and let 3 happen
> organically when the community has a need.
>
> On Tue, Nov 15, 2016 at 9:29 AM, David Lyle  wrote:
>
> > I think that's an excellent understanding and suggestion on #3.
> >
> > Fwiw, the norm I've seen is to allow the requester and the dev to work
> that
> > out.
> >
> > Thanks,
> >
> > -D...
> >
> >
> > On Tue, Nov 15, 2016 at 11:22 AM, Nick Allen 
> wrote:
> >
> > > I broke down what I am understanding of your suggestion into bullet
> > > points. Please correct me if I am wrong.
> > >
> > > (1) Bump the rev immediately following a release
> > > (2) Update the current version in master to 0.4.0
> > > (3) Maintain and back port bug fixes to a 0.3.x branch
> > >
> > >
> > > I would agree with you on items (1) and (2); +1 on those.
> > >
> > > Item (3) is what drove my questions. I feel this needs a little more
> > > discussion to outline what gets back ported, how it is back ported and
> > when
> > > that might occur. I am not concerned about the technicalities of
> > > maintaining multiple branches, more the process side of things.
> > >
> > > Maybe we could sit on (3) until there is a community member with an
> > > interest in back porting a fix? Right now, I don't know of any, but
> maybe
> > > I've missed a conversation.
> > >
> > >
> > >
> > >
> > >
> > > On Tue, Nov 15, 2016 at 10:42 AM, David Lyle 
> > wrote:
> > >
> > > > So, the notion is- we're going to have a 0.4.0 release at some
> future
> > > > point. If, during that release cycle, we found critical bug fix type
> > > issues
> > > > that we wanted to release out of cycle, we could patch the 0.3.0
> branch
> > > and
> > > > cut a release from there. You're correct that we'd have to commit
> them
> > to
> > > > both branches. I don't know of a way to avoid that with that type of
> > > stuff,
> > > > so I think the best we can do is to minimize them.
> > > >
> > > > Alternatively, we can decide that the next release will be 0.3.1 and
> > > either
> > > > abandon the notion of semantic versioning [1] (i.e. put features and
> > bug
> > > > fixes in a x.x.1 release) or only release bug fixes.
> > > >
> > > > I don't really have a strong preference excepting that I know for
> sure
> > > that
> > > > master will no longer be 0.3.0 once 0.3.0 is released, so we should
> > bump
> > > > the rev immediately following the 0.3.0 release (if not sooner).
> > > >
> > > > -D...
> > > >
> > > > [1] http://semver.org/
> > > >
> > > >
> > > > On Tue, Nov 15, 2016 at 9:52 AM, Nick Allen 
> > wrote:
> > > >
> > > > > What kind of PRs would qualify as 0.3.x fixes? How would we decide
> > > that?
> > > > > For those we would then have to commit them against both the 0.3.x
> > > branch
> > > > > and master (0.4.0), right?
> > > > >
> > > > > Off the top of your head, can you think of a few recent PRs that
> > would
> > > > > qualify as patches? I'd just like to get a feel for how many of
> > those
> > > > > might exist.
> > > > >
> > > > >
> > > > >
> > > > > On Mon, Nov 14, 2016 at 6:58 PM, David Lyle 
>
> > > > wrote:
> > > > >
> > > > > > Hi Mike,
> > > > > >
> > > > > > I'd like to see us increment the version on master ASAP. Once
> 0.3.0
> > > is
> > > > > > released, master is no longer the 0.3.0 branch.
> > > > > >
> > > > > > I recommend that we run 0.3.x patches off the 0.3.0 release
> branch
> > > and
> > > > > > rename master to 0.4.0.
> > > > > >
> > > > > > Thanks,
> > > > > >
> > > > > > -D...
> > > > > >
> > > > > >
> > > > > > On Mon, Nov 14, 2016 at 4:40 PM, Michael Miklavcic <
> > > > > > michael.miklav...@gmail.com> wrote:
> > > > > >
> > > > > > > 1 - What the next version should be.
> > > > > > > 2 - When we should increment the version
> > > > > > >
> > > > > > > On Mon, Nov 14, 2016 at 2:35 PM, zeo...@gmail.com <
> > > zeo...@gmail.com>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Sorry, but I don't exactly follow. Are you looking to
> discuss
> > > what
> > > > > the
> > > > > > > > version number should be next time around (1.0 vs 0.4 vs
> > 0.3.1?)
> > > or
> > > > > > what
> > > > > > > > tasks need to be accomplished before the next version of
> metron
> 

Re: [DISCUSS] Metron next version rev

[Otto Fowler]

Would the back ports also have to go through a full ‘apache release’ process 
and be planned out as well?
I don’t think that should all be worked out as we go.


On November 15, 2016 at 12:13:55, Michael Miklavcic 
(michael.miklav...@gmail.com) wrote:

I'm a +1 on David and Nick's suggestions. 1 and 2 now, and let 3 happen  
organically when the community has a need.  

On Tue, Nov 15, 2016 at 9:29 AM, David Lyle  wrote:  

> I think that's an excellent understanding and suggestion on #3.  
>  
> Fwiw, the norm I've seen is to allow the requester and the dev to work that  
> out.  
>  
> Thanks,  
>  
> -D...  
>  
>  
> On Tue, Nov 15, 2016 at 11:22 AM, Nick Allen  wrote:  
>  
> > I broke down what I am understanding of your suggestion into bullet  
> > points. Please correct me if I am wrong.  
> >  
> > (1) Bump the rev immediately following a release  
> > (2) Update the current version in master to 0.4.0  
> > (3) Maintain and back port bug fixes to a 0.3.x branch  
> >  
> >  
> > I would agree with you on items (1) and (2); +1 on those.  
> >  
> > Item (3) is what drove my questions. I feel this needs a little more  
> > discussion to outline what gets back ported, how it is back ported and  
> when  
> > that might occur. I am not concerned about the technicalities of  
> > maintaining multiple branches, more the process side of things.  
> >  
> > Maybe we could sit on (3) until there is a community member with an  
> > interest in back porting a fix? Right now, I don't know of any, but maybe  
> > I've missed a conversation.  
> >  
> >  
> >  
> >  
> >  
> > On Tue, Nov 15, 2016 at 10:42 AM, David Lyle   
> wrote:  
> >  
> > > So, the notion is- we're going to have a 0.4.0 release at some future  
> > > point. If, during that release cycle, we found critical bug fix type  
> > issues  
> > > that we wanted to release out of cycle, we could patch the 0.3.0 branch  
> > and  
> > > cut a release from there. You're correct that we'd have to commit them  
> to  
> > > both branches. I don't know of a way to avoid that with that type of  
> > stuff,  
> > > so I think the best we can do is to minimize them.  
> > >  
> > > Alternatively, we can decide that the next release will be 0.3.1 and  
> > either  
> > > abandon the notion of semantic versioning [1] (i.e. put features and  
> bug  
> > > fixes in a x.x.1 release) or only release bug fixes.  
> > >  
> > > I don't really have a strong preference excepting that I know for sure  
> > that  
> > > master will no longer be 0.3.0 once 0.3.0 is released, so we should  
> bump  
> > > the rev immediately following the 0.3.0 release (if not sooner).  
> > >  
> > > -D...  
> > >  
> > > [1] http://semver.org/  
> > >  
> > >  
> > > On Tue, Nov 15, 2016 at 9:52 AM, Nick Allen   
> wrote:  
> > >  
> > > > What kind of PRs would qualify as 0.3.x fixes? How would we decide  
> > that?  
> > > > For those we would then have to commit them against both the 0.3.x  
> > branch  
> > > > and master (0.4.0), right?  
> > > >  
> > > > Off the top of your head, can you think of a few recent PRs that  
> would  
> > > > qualify as patches? I'd just like to get a feel for how many of  
> those  
> > > > might exist.  
> > > >  
> > > >  
> > > >  
> > > > On Mon, Nov 14, 2016 at 6:58 PM, David Lyle   
> > > wrote:  
> > > >  
> > > > > Hi Mike,  
> > > > >  
> > > > > I'd like to see us increment the version on master ASAP. Once 0.3.0  
> > is  
> > > > > released, master is no longer the 0.3.0 branch.  
> > > > >  
> > > > > I recommend that we run 0.3.x patches off the 0.3.0 release branch  
> > and  
> > > > > rename master to 0.4.0.  
> > > > >  
> > > > > Thanks,  
> > > > >  
> > > > > -D...  
> > > > >  
> > > > >  
> > > > > On Mon, Nov 14, 2016 at 4:40 PM, Michael Miklavcic <  
> > > > > michael.miklav...@gmail.com> wrote:  
> > > > >  
> > > > > > 1 - What the next version should be.  
> > > > > > 2 - When we should increment the version  
> > > > > >  
> > > > > > On Mon, Nov 14, 2016 at 2:35 PM, zeo...@gmail.com <  
> > zeo...@gmail.com>  
> > > > > > wrote:  
> > > > > >  
> > > > > > > Sorry, but I don't exactly follow. Are you looking to discuss  
> > what  
> > > > the  
> > > > > > > version number should be next time around (1.0 vs 0.4 vs  
> 0.3.1?)  
> > or  
> > > > > what  
> > > > > > > tasks need to be accomplished before the next version of metron  
> > is  
> > > > > > > considered ready? Thanks,  
> > > > > > >  
> > > > > > > Jon  
> > > > > > >  
> > > > > > > On Mon, Nov 14, 2016, 16:29 Michael Miklavcic <  
> > > > > > michael.miklav...@gmail.com  
> > > > > > > >  
> > > > > > > wrote:  
> > > > > > >  
> > > > > > > > This is a thread to discuss what the next version of Metron  
> > > should  
> > > > be  
> > > > > > > > after Apache  
> > > > > > > > Metron 0.3.0-RC1 incubating is released, e.g. 0.3.1?  
> > > > > > > > 

Re: [DISCUSS] Metron next version rev

[Michael Miklavcic]

I'm a +1 on David and Nick's suggestions. 1 and 2 now, and let 3 happen
organically when the community has a need.

On Tue, Nov 15, 2016 at 9:29 AM, David Lyle  wrote:

> I think that's an excellent understanding and suggestion on #3.
>
> Fwiw, the norm I've seen is to allow the requester and the dev to work that
> out.
>
> Thanks,
>
> -D...
>
>
> On Tue, Nov 15, 2016 at 11:22 AM, Nick Allen  wrote:
>
> > I broke down what I am understanding of your suggestion into bullet
> > points.  Please correct me if I am wrong.
> >
> > (1) Bump the rev immediately following a release
> > (2) Update the current version in master to 0.4.0
> > (3) Maintain and back port bug fixes to a 0.3.x branch
> >
> >
> > I would agree with you on items (1) and (2); +1 on those.
> >
> > Item (3) is what drove my questions.  I feel this needs a little more
> > discussion to outline what gets back ported, how it is back ported and
> when
> > that might occur.  I am not concerned about the technicalities of
> > maintaining multiple branches, more the process side of things.
> >
> > Maybe we could sit on (3) until there is a community member with an
> > interest in back porting a fix? Right now, I don't know of any, but maybe
> > I've missed a conversation.
> >
> >
> >
> >
> >
> > On Tue, Nov 15, 2016 at 10:42 AM, David Lyle 
> wrote:
> >
> > > So, the notion is- we're going to have a 0.4.0 release at some future
> > > point. If, during that release cycle, we found critical bug fix type
> > issues
> > > that we wanted to release out of cycle, we could patch the 0.3.0 branch
> > and
> > > cut a release from there. You're correct that we'd have to commit them
> to
> > > both branches. I don't know of a way to avoid that with that type of
> > stuff,
> > > so I think the best we can do is to minimize them.
> > >
> > > Alternatively, we can decide that the next release will be 0.3.1 and
> > either
> > > abandon the notion of semantic versioning [1] (i.e. put features and
> bug
> > > fixes in a x.x.1 release) or only release bug fixes.
> > >
> > > I don't really have a strong preference excepting that I know for sure
> > that
> > > master will no longer be 0.3.0 once 0.3.0 is released, so we should
> bump
> > > the rev immediately following the 0.3.0 release (if not sooner).
> > >
> > > -D...
> > >
> > > [1] http://semver.org/
> > >
> > >
> > > On Tue, Nov 15, 2016 at 9:52 AM, Nick Allen 
> wrote:
> > >
> > > > What kind of PRs would qualify as 0.3.x fixes?  How would we decide
> > that?
> > > > For those we would then have to commit them against both the 0.3.x
> > branch
> > > > and master (0.4.0), right?
> > > >
> > > > Off the top of your head, can you think of a few recent PRs that
> would
> > > > qualify as patches?  I'd just like to get a feel for how many of
> those
> > > > might exist.
> > > >
> > > >
> > > >
> > > > On Mon, Nov 14, 2016 at 6:58 PM, David Lyle 
> > > wrote:
> > > >
> > > > > Hi Mike,
> > > > >
> > > > > I'd like to see us increment the version on master ASAP. Once 0.3.0
> > is
> > > > > released, master is no longer the 0.3.0 branch.
> > > > >
> > > > > I recommend that we run 0.3.x patches off the 0.3.0 release branch
> > and
> > > > > rename master to 0.4.0.
> > > > >
> > > > > Thanks,
> > > > >
> > > > > -D...
> > > > >
> > > > >
> > > > > On Mon, Nov 14, 2016 at 4:40 PM, Michael Miklavcic <
> > > > > michael.miklav...@gmail.com> wrote:
> > > > >
> > > > > > 1 - What the next version should be.
> > > > > > 2 - When we should increment the version
> > > > > >
> > > > > > On Mon, Nov 14, 2016 at 2:35 PM, zeo...@gmail.com <
> > zeo...@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > Sorry, but I don't exactly follow.  Are you looking to discuss
> > what
> > > > the
> > > > > > > version number should be next time around (1.0 vs 0.4 vs
> 0.3.1?)
> > or
> > > > > what
> > > > > > > tasks need to be accomplished before the next version of metron
> > is
> > > > > > > considered ready?  Thanks,
> > > > > > >
> > > > > > > Jon
> > > > > > >
> > > > > > > On Mon, Nov 14, 2016, 16:29 Michael Miklavcic <
> > > > > > michael.miklav...@gmail.com
> > > > > > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > > > This is a thread to discuss what the next version of Metron
> > > should
> > > > be
> > > > > > > > after Apache
> > > > > > > > Metron 0.3.0-RC1 incubating is released, e.g. 0.3.1?
> > > > > > > >
> > > > > > > > I'd like to up the rev asap, however one thing to consider is
> > > that
> > > > we
> > > > > > > might
> > > > > > > > change the version again at a later point in time prior to
> the
> > > next
> > > > > > > > release. This current release candidate being a case in
> point.
> > On
> > > > the
> > > > > > > other
> > > > > > > > hand, I am also currently working on simplifying the version
> > > change
> > > > > > > process
> > > > > > > > so it might not be a big deal either way.
> > > > > > > >
> > 

Re: [DISCUSS] Metron next version rev

[David Lyle]

I think that's an excellent understanding and suggestion on #3.

Fwiw, the norm I've seen is to allow the requester and the dev to work that
out.

Thanks,

-D...


On Tue, Nov 15, 2016 at 11:22 AM, Nick Allen  wrote:

> I broke down what I am understanding of your suggestion into bullet
> points.  Please correct me if I am wrong.
>
> (1) Bump the rev immediately following a release
> (2) Update the current version in master to 0.4.0
> (3) Maintain and back port bug fixes to a 0.3.x branch
>
>
> I would agree with you on items (1) and (2); +1 on those.
>
> Item (3) is what drove my questions.  I feel this needs a little more
> discussion to outline what gets back ported, how it is back ported and when
> that might occur.  I am not concerned about the technicalities of
> maintaining multiple branches, more the process side of things.
>
> Maybe we could sit on (3) until there is a community member with an
> interest in back porting a fix? Right now, I don't know of any, but maybe
> I've missed a conversation.
>
>
>
>
>
> On Tue, Nov 15, 2016 at 10:42 AM, David Lyle  wrote:
>
> > So, the notion is- we're going to have a 0.4.0 release at some future
> > point. If, during that release cycle, we found critical bug fix type
> issues
> > that we wanted to release out of cycle, we could patch the 0.3.0 branch
> and
> > cut a release from there. You're correct that we'd have to commit them to
> > both branches. I don't know of a way to avoid that with that type of
> stuff,
> > so I think the best we can do is to minimize them.
> >
> > Alternatively, we can decide that the next release will be 0.3.1 and
> either
> > abandon the notion of semantic versioning [1] (i.e. put features and bug
> > fixes in a x.x.1 release) or only release bug fixes.
> >
> > I don't really have a strong preference excepting that I know for sure
> that
> > master will no longer be 0.3.0 once 0.3.0 is released, so we should bump
> > the rev immediately following the 0.3.0 release (if not sooner).
> >
> > -D...
> >
> > [1] http://semver.org/
> >
> >
> > On Tue, Nov 15, 2016 at 9:52 AM, Nick Allen  wrote:
> >
> > > What kind of PRs would qualify as 0.3.x fixes?  How would we decide
> that?
> > > For those we would then have to commit them against both the 0.3.x
> branch
> > > and master (0.4.0), right?
> > >
> > > Off the top of your head, can you think of a few recent PRs that would
> > > qualify as patches?  I'd just like to get a feel for how many of those
> > > might exist.
> > >
> > >
> > >
> > > On Mon, Nov 14, 2016 at 6:58 PM, David Lyle 
> > wrote:
> > >
> > > > Hi Mike,
> > > >
> > > > I'd like to see us increment the version on master ASAP. Once 0.3.0
> is
> > > > released, master is no longer the 0.3.0 branch.
> > > >
> > > > I recommend that we run 0.3.x patches off the 0.3.0 release branch
> and
> > > > rename master to 0.4.0.
> > > >
> > > > Thanks,
> > > >
> > > > -D...
> > > >
> > > >
> > > > On Mon, Nov 14, 2016 at 4:40 PM, Michael Miklavcic <
> > > > michael.miklav...@gmail.com> wrote:
> > > >
> > > > > 1 - What the next version should be.
> > > > > 2 - When we should increment the version
> > > > >
> > > > > On Mon, Nov 14, 2016 at 2:35 PM, zeo...@gmail.com <
> zeo...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Sorry, but I don't exactly follow.  Are you looking to discuss
> what
> > > the
> > > > > > version number should be next time around (1.0 vs 0.4 vs 0.3.1?)
> or
> > > > what
> > > > > > tasks need to be accomplished before the next version of metron
> is
> > > > > > considered ready?  Thanks,
> > > > > >
> > > > > > Jon
> > > > > >
> > > > > > On Mon, Nov 14, 2016, 16:29 Michael Miklavcic <
> > > > > michael.miklav...@gmail.com
> > > > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > This is a thread to discuss what the next version of Metron
> > should
> > > be
> > > > > > > after Apache
> > > > > > > Metron 0.3.0-RC1 incubating is released, e.g. 0.3.1?
> > > > > > >
> > > > > > > I'd like to up the rev asap, however one thing to consider is
> > that
> > > we
> > > > > > might
> > > > > > > change the version again at a later point in time prior to the
> > next
> > > > > > > release. This current release candidate being a case in point.
> On
> > > the
> > > > > > other
> > > > > > > hand, I am also currently working on simplifying the version
> > change
> > > > > > process
> > > > > > > so it might not be a big deal either way.
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Mike Miklavcic
> > > > > > >
> > > > > > --
> > > > > >
> > > > > > Jon
> > > > > >
> > > > > > Sent from my mobile device
> > > > > >
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Nick Allen 
> > >
> >
>
>
>
> --
> Nick Allen 
>

Re: [DISCUSS] Metron next version rev

[Nick Allen]

I broke down what I am understanding of your suggestion into bullet
points.  Please correct me if I am wrong.

(1) Bump the rev immediately following a release
(2) Update the current version in master to 0.4.0
(3) Maintain and back port bug fixes to a 0.3.x branch


I would agree with you on items (1) and (2); +1 on those.

Item (3) is what drove my questions.  I feel this needs a little more
discussion to outline what gets back ported, how it is back ported and when
that might occur.  I am not concerned about the technicalities of
maintaining multiple branches, more the process side of things.

Maybe we could sit on (3) until there is a community member with an
interest in back porting a fix? Right now, I don't know of any, but maybe
I've missed a conversation.





On Tue, Nov 15, 2016 at 10:42 AM, David Lyle  wrote:

> So, the notion is- we're going to have a 0.4.0 release at some future
> point. If, during that release cycle, we found critical bug fix type issues
> that we wanted to release out of cycle, we could patch the 0.3.0 branch and
> cut a release from there. You're correct that we'd have to commit them to
> both branches. I don't know of a way to avoid that with that type of stuff,
> so I think the best we can do is to minimize them.
>
> Alternatively, we can decide that the next release will be 0.3.1 and either
> abandon the notion of semantic versioning [1] (i.e. put features and bug
> fixes in a x.x.1 release) or only release bug fixes.
>
> I don't really have a strong preference excepting that I know for sure that
> master will no longer be 0.3.0 once 0.3.0 is released, so we should bump
> the rev immediately following the 0.3.0 release (if not sooner).
>
> -D...
>
> [1] http://semver.org/
>
>
> On Tue, Nov 15, 2016 at 9:52 AM, Nick Allen  wrote:
>
> > What kind of PRs would qualify as 0.3.x fixes?  How would we decide that?
> > For those we would then have to commit them against both the 0.3.x branch
> > and master (0.4.0), right?
> >
> > Off the top of your head, can you think of a few recent PRs that would
> > qualify as patches?  I'd just like to get a feel for how many of those
> > might exist.
> >
> >
> >
> > On Mon, Nov 14, 2016 at 6:58 PM, David Lyle 
> wrote:
> >
> > > Hi Mike,
> > >
> > > I'd like to see us increment the version on master ASAP. Once 0.3.0 is
> > > released, master is no longer the 0.3.0 branch.
> > >
> > > I recommend that we run 0.3.x patches off the 0.3.0 release branch and
> > > rename master to 0.4.0.
> > >
> > > Thanks,
> > >
> > > -D...
> > >
> > >
> > > On Mon, Nov 14, 2016 at 4:40 PM, Michael Miklavcic <
> > > michael.miklav...@gmail.com> wrote:
> > >
> > > > 1 - What the next version should be.
> > > > 2 - When we should increment the version
> > > >
> > > > On Mon, Nov 14, 2016 at 2:35 PM, zeo...@gmail.com 
> > > > wrote:
> > > >
> > > > > Sorry, but I don't exactly follow.  Are you looking to discuss what
> > the
> > > > > version number should be next time around (1.0 vs 0.4 vs 0.3.1?) or
> > > what
> > > > > tasks need to be accomplished before the next version of metron is
> > > > > considered ready?  Thanks,
> > > > >
> > > > > Jon
> > > > >
> > > > > On Mon, Nov 14, 2016, 16:29 Michael Miklavcic <
> > > > michael.miklav...@gmail.com
> > > > > >
> > > > > wrote:
> > > > >
> > > > > > This is a thread to discuss what the next version of Metron
> should
> > be
> > > > > > after Apache
> > > > > > Metron 0.3.0-RC1 incubating is released, e.g. 0.3.1?
> > > > > >
> > > > > > I'd like to up the rev asap, however one thing to consider is
> that
> > we
> > > > > might
> > > > > > change the version again at a later point in time prior to the
> next
> > > > > > release. This current release candidate being a case in point. On
> > the
> > > > > other
> > > > > > hand, I am also currently working on simplifying the version
> change
> > > > > process
> > > > > > so it might not be a big deal either way.
> > > > > >
> > > > > > Thanks,
> > > > > > Mike Miklavcic
> > > > > >
> > > > > --
> > > > >
> > > > > Jon
> > > > >
> > > > > Sent from my mobile device
> > > > >
> > > >
> > >
> >
> >
> >
> > --
> > Nick Allen 
> >
>



-- 
Nick Allen 

Re: [DISCUSS] Metron next version rev

[David Lyle]

So, the notion is- we're going to have a 0.4.0 release at some future
point. If, during that release cycle, we found critical bug fix type issues
that we wanted to release out of cycle, we could patch the 0.3.0 branch and
cut a release from there. You're correct that we'd have to commit them to
both branches. I don't know of a way to avoid that with that type of stuff,
so I think the best we can do is to minimize them.

Alternatively, we can decide that the next release will be 0.3.1 and either
abandon the notion of semantic versioning [1] (i.e. put features and bug
fixes in a x.x.1 release) or only release bug fixes.

I don't really have a strong preference excepting that I know for sure that
master will no longer be 0.3.0 once 0.3.0 is released, so we should bump
the rev immediately following the 0.3.0 release (if not sooner).

-D...

[1] http://semver.org/


On Tue, Nov 15, 2016 at 9:52 AM, Nick Allen  wrote:

> What kind of PRs would qualify as 0.3.x fixes?  How would we decide that?
> For those we would then have to commit them against both the 0.3.x branch
> and master (0.4.0), right?
>
> Off the top of your head, can you think of a few recent PRs that would
> qualify as patches?  I'd just like to get a feel for how many of those
> might exist.
>
>
>
> On Mon, Nov 14, 2016 at 6:58 PM, David Lyle  wrote:
>
> > Hi Mike,
> >
> > I'd like to see us increment the version on master ASAP. Once 0.3.0 is
> > released, master is no longer the 0.3.0 branch.
> >
> > I recommend that we run 0.3.x patches off the 0.3.0 release branch and
> > rename master to 0.4.0.
> >
> > Thanks,
> >
> > -D...
> >
> >
> > On Mon, Nov 14, 2016 at 4:40 PM, Michael Miklavcic <
> > michael.miklav...@gmail.com> wrote:
> >
> > > 1 - What the next version should be.
> > > 2 - When we should increment the version
> > >
> > > On Mon, Nov 14, 2016 at 2:35 PM, zeo...@gmail.com 
> > > wrote:
> > >
> > > > Sorry, but I don't exactly follow.  Are you looking to discuss what
> the
> > > > version number should be next time around (1.0 vs 0.4 vs 0.3.1?) or
> > what
> > > > tasks need to be accomplished before the next version of metron is
> > > > considered ready?  Thanks,
> > > >
> > > > Jon
> > > >
> > > > On Mon, Nov 14, 2016, 16:29 Michael Miklavcic <
> > > michael.miklav...@gmail.com
> > > > >
> > > > wrote:
> > > >
> > > > > This is a thread to discuss what the next version of Metron should
> be
> > > > > after Apache
> > > > > Metron 0.3.0-RC1 incubating is released, e.g. 0.3.1?
> > > > >
> > > > > I'd like to up the rev asap, however one thing to consider is that
> we
> > > > might
> > > > > change the version again at a later point in time prior to the next
> > > > > release. This current release candidate being a case in point. On
> the
> > > > other
> > > > > hand, I am also currently working on simplifying the version change
> > > > process
> > > > > so it might not be a big deal either way.
> > > > >
> > > > > Thanks,
> > > > > Mike Miklavcic
> > > > >
> > > > --
> > > >
> > > > Jon
> > > >
> > > > Sent from my mobile device
> > > >
> > >
> >
>
>
>
> --
> Nick Allen 
>

Re: [DISCUSS] Metron next version rev

[Michael Miklavcic]

We'd cut a release from master - we'd initially increment to 0.4.0-SNAPSHOT
with the approach David is recommending. And any patches in 0.3.x would
need to also be applied to master.

On Tue, Nov 15, 2016 at 7:57 AM, Nick Allen  wrote:

> And where would the next release get cut from; master or the 0.3.x branch?
> Or is that something we decide when we cut a release based on what we want
> to include?
>
>
>
> On Tue, Nov 15, 2016 at 9:52 AM, Nick Allen  wrote:
>
> > What kind of PRs would qualify as 0.3.x fixes?  How would we decide that?
> > For those we would then have to commit them against both the 0.3.x branch
> > and master (0.4.0), right?
> >
> > Off the top of your head, can you think of a few recent PRs that would
> > qualify as patches?  I'd just like to get a feel for how many of those
> > might exist.
> >
> >
> >
> > On Mon, Nov 14, 2016 at 6:58 PM, David Lyle 
> wrote:
> >
> >> Hi Mike,
> >>
> >> I'd like to see us increment the version on master ASAP. Once 0.3.0 is
> >> released, master is no longer the 0.3.0 branch.
> >>
> >> I recommend that we run 0.3.x patches off the 0.3.0 release branch and
> >> rename master to 0.4.0.
> >>
> >> Thanks,
> >>
> >> -D...
> >>
> >>
> >> On Mon, Nov 14, 2016 at 4:40 PM, Michael Miklavcic <
> >> michael.miklav...@gmail.com> wrote:
> >>
> >> > 1 - What the next version should be.
> >> > 2 - When we should increment the version
> >> >
> >> > On Mon, Nov 14, 2016 at 2:35 PM, zeo...@gmail.com 
> >> > wrote:
> >> >
> >> > > Sorry, but I don't exactly follow.  Are you looking to discuss what
> >> the
> >> > > version number should be next time around (1.0 vs 0.4 vs 0.3.1?) or
> >> what
> >> > > tasks need to be accomplished before the next version of metron is
> >> > > considered ready?  Thanks,
> >> > >
> >> > > Jon
> >> > >
> >> > > On Mon, Nov 14, 2016, 16:29 Michael Miklavcic <
> >> > michael.miklav...@gmail.com
> >> > > >
> >> > > wrote:
> >> > >
> >> > > > This is a thread to discuss what the next version of Metron should
> >> be
> >> > > > after Apache
> >> > > > Metron 0.3.0-RC1 incubating is released, e.g. 0.3.1?
> >> > > >
> >> > > > I'd like to up the rev asap, however one thing to consider is that
> >> we
> >> > > might
> >> > > > change the version again at a later point in time prior to the
> next
> >> > > > release. This current release candidate being a case in point. On
> >> the
> >> > > other
> >> > > > hand, I am also currently working on simplifying the version
> change
> >> > > process
> >> > > > so it might not be a big deal either way.
> >> > > >
> >> > > > Thanks,
> >> > > > Mike Miklavcic
> >> > > >
> >> > > --
> >> > >
> >> > > Jon
> >> > >
> >> > > Sent from my mobile device
> >> > >
> >> >
> >>
> >
> >
> >
> > --
> > Nick Allen 
> >
>
>
>
> --
> Nick Allen 
>

Re: [DISCUSS] Metron next version rev

[Nick Allen]

And where would the next release get cut from; master or the 0.3.x branch?
Or is that something we decide when we cut a release based on what we want
to include?



On Tue, Nov 15, 2016 at 9:52 AM, Nick Allen  wrote:

> What kind of PRs would qualify as 0.3.x fixes?  How would we decide that?
> For those we would then have to commit them against both the 0.3.x branch
> and master (0.4.0), right?
>
> Off the top of your head, can you think of a few recent PRs that would
> qualify as patches?  I'd just like to get a feel for how many of those
> might exist.
>
>
>
> On Mon, Nov 14, 2016 at 6:58 PM, David Lyle  wrote:
>
>> Hi Mike,
>>
>> I'd like to see us increment the version on master ASAP. Once 0.3.0 is
>> released, master is no longer the 0.3.0 branch.
>>
>> I recommend that we run 0.3.x patches off the 0.3.0 release branch and
>> rename master to 0.4.0.
>>
>> Thanks,
>>
>> -D...
>>
>>
>> On Mon, Nov 14, 2016 at 4:40 PM, Michael Miklavcic <
>> michael.miklav...@gmail.com> wrote:
>>
>> > 1 - What the next version should be.
>> > 2 - When we should increment the version
>> >
>> > On Mon, Nov 14, 2016 at 2:35 PM, zeo...@gmail.com 
>> > wrote:
>> >
>> > > Sorry, but I don't exactly follow.  Are you looking to discuss what
>> the
>> > > version number should be next time around (1.0 vs 0.4 vs 0.3.1?) or
>> what
>> > > tasks need to be accomplished before the next version of metron is
>> > > considered ready?  Thanks,
>> > >
>> > > Jon
>> > >
>> > > On Mon, Nov 14, 2016, 16:29 Michael Miklavcic <
>> > michael.miklav...@gmail.com
>> > > >
>> > > wrote:
>> > >
>> > > > This is a thread to discuss what the next version of Metron should
>> be
>> > > > after Apache
>> > > > Metron 0.3.0-RC1 incubating is released, e.g. 0.3.1?
>> > > >
>> > > > I'd like to up the rev asap, however one thing to consider is that
>> we
>> > > might
>> > > > change the version again at a later point in time prior to the next
>> > > > release. This current release candidate being a case in point. On
>> the
>> > > other
>> > > > hand, I am also currently working on simplifying the version change
>> > > process
>> > > > so it might not be a big deal either way.
>> > > >
>> > > > Thanks,
>> > > > Mike Miklavcic
>> > > >
>> > > --
>> > >
>> > > Jon
>> > >
>> > > Sent from my mobile device
>> > >
>> >
>>
>
>
>
> --
> Nick Allen 
>



-- 
Nick Allen 

Re: [DISCUSS] Metron next version rev

[Nick Allen]

What kind of PRs would qualify as 0.3.x fixes?  How would we decide that?
For those we would then have to commit them against both the 0.3.x branch
and master (0.4.0), right?

Off the top of your head, can you think of a few recent PRs that would
qualify as patches?  I'd just like to get a feel for how many of those
might exist.



On Mon, Nov 14, 2016 at 6:58 PM, David Lyle  wrote:

> Hi Mike,
>
> I'd like to see us increment the version on master ASAP. Once 0.3.0 is
> released, master is no longer the 0.3.0 branch.
>
> I recommend that we run 0.3.x patches off the 0.3.0 release branch and
> rename master to 0.4.0.
>
> Thanks,
>
> -D...
>
>
> On Mon, Nov 14, 2016 at 4:40 PM, Michael Miklavcic <
> michael.miklav...@gmail.com> wrote:
>
> > 1 - What the next version should be.
> > 2 - When we should increment the version
> >
> > On Mon, Nov 14, 2016 at 2:35 PM, zeo...@gmail.com 
> > wrote:
> >
> > > Sorry, but I don't exactly follow.  Are you looking to discuss what the
> > > version number should be next time around (1.0 vs 0.4 vs 0.3.1?) or
> what
> > > tasks need to be accomplished before the next version of metron is
> > > considered ready?  Thanks,
> > >
> > > Jon
> > >
> > > On Mon, Nov 14, 2016, 16:29 Michael Miklavcic <
> > michael.miklav...@gmail.com
> > > >
> > > wrote:
> > >
> > > > This is a thread to discuss what the next version of Metron should be
> > > > after Apache
> > > > Metron 0.3.0-RC1 incubating is released, e.g. 0.3.1?
> > > >
> > > > I'd like to up the rev asap, however one thing to consider is that we
> > > might
> > > > change the version again at a later point in time prior to the next
> > > > release. This current release candidate being a case in point. On the
> > > other
> > > > hand, I am also currently working on simplifying the version change
> > > process
> > > > so it might not be a big deal either way.
> > > >
> > > > Thanks,
> > > > Mike Miklavcic
> > > >
> > > --
> > >
> > > Jon
> > >
> > > Sent from my mobile device
> > >
> >
>



-- 
Nick Allen 

Re: [DISCUSS] Metron next version rev

[David Lyle]

Hi Mike,

I'd like to see us increment the version on master ASAP. Once 0.3.0 is
released, master is no longer the 0.3.0 branch.

I recommend that we run 0.3.x patches off the 0.3.0 release branch and
rename master to 0.4.0.

Thanks,

-D...


On Mon, Nov 14, 2016 at 4:40 PM, Michael Miklavcic <
michael.miklav...@gmail.com> wrote:

> 1 - What the next version should be.
> 2 - When we should increment the version
>
> On Mon, Nov 14, 2016 at 2:35 PM, zeo...@gmail.com 
> wrote:
>
> > Sorry, but I don't exactly follow.  Are you looking to discuss what the
> > version number should be next time around (1.0 vs 0.4 vs 0.3.1?) or what
> > tasks need to be accomplished before the next version of metron is
> > considered ready?  Thanks,
> >
> > Jon
> >
> > On Mon, Nov 14, 2016, 16:29 Michael Miklavcic <
> michael.miklav...@gmail.com
> > >
> > wrote:
> >
> > > This is a thread to discuss what the next version of Metron should be
> > > after Apache
> > > Metron 0.3.0-RC1 incubating is released, e.g. 0.3.1?
> > >
> > > I'd like to up the rev asap, however one thing to consider is that we
> > might
> > > change the version again at a later point in time prior to the next
> > > release. This current release candidate being a case in point. On the
> > other
> > > hand, I am also currently working on simplifying the version change
> > process
> > > so it might not be a big deal either way.
> > >
> > > Thanks,
> > > Mike Miklavcic
> > >
> > --
> >
> > Jon
> >
> > Sent from my mobile device
> >
>