Distinguishing between 0.2.0 vs 0.1.1 ?

[Dan Bress <db...@onyxconsults.com>]

Hi,

Joe recently brought up the idea of thinking about what new features go in 0.2.0 and what bug fixes go in 0.1.1. Did we make a decision on that? I bring it up because I could see three tickets being fixed/released (quickly) in 0.1.1 (NIFI-633, NIFI-632, NIFI-638).


If we decide to do an 0.1.1, did we decide how that gets handled from a git/branching point of view?  Currently develop is labeled '0.1.1-SNAPSHOT', and so is release-nifi-0.1.0-rc13<https://github.com/apache/incubator-nifi/tree/release-nifi-0.1.0-rc13>.


So where would 0.1.1 fixes go, and where would 0.2.0 features go?



Dan Bress
Software Engineer
ONYX Consulting Services

Re: Distinguishing between 0.2.0 vs 0.1.1 ?

[Joe Witt <jo...@gmail.com>]

Tony,

The tag name itself having the RC# is intentional and specified in the
release guide.  Having the RC# in the release version itself which
ends up on the code and thus reflects in the UI is not intentional.
Though I just looked at the actual tagged release code and it does not
have the RC# in there except for the scm/tag section which is
expected.  However, for the running instance of nifi to show its
version is '0.1.0-incubating-RC13' that means that
'${project.version}' while building the assembly was
'0.1.0-incubating-RC13' and that I don't understand given that the
version is proper at '0.1.0-incubating'.

I'm confused.

Joe

On Wed, Jun 3, 2015 at 10:51 PM, Tony Kurc <tr...@gmail.com> wrote:
> It sounds like it was unintentional. FWIW The other releases also had an
> RC# tacked on the tag.
>
> On Wed, Jun 3, 2015 at 10:48 PM, Joe Witt <jo...@gmail.com> wrote:
>
>> Tony
>>
>> I have not confirmed this but what I would guess happened is a mistake
>> during the release process.  If you look here
>> http://nifi.incubator.apache.org/release-guide.html it outlines the
>> proper responses for the questions maven asks.
>>
>> I think the wrong version name was used specifically for this question:
>>
>> "What is the release version for "Apache NiFi"? (org.apache.nifi:nifi)
>> 0.0.1-incubating: :"
>>
>> The only one that requires manual entry is this one:
>>
>> "What is SCM release tag or label for "Apache NiFi"?
>> (org.apache.nifi:nifi) nifi-0.0.1-incubating: :"
>>
>> Mark P: Can you confirm if this mistake was possibly made?  That is
>> the only way I can see how this would have ended up in the build like
>> that.
>>
>> Thanks
>> Joe
>>
>> On Wed, Jun 3, 2015 at 10:38 PM, Tony Kurc <tr...@gmail.com> wrote:
>> > Speaking of which, I'm a bit confused about the tags in git. Why is
>> there a
>> > RC13 on the recent release?
>> >
>> > On Wed, Jun 3, 2015 at 10:12 PM, Joe Witt <jo...@gmail.com> wrote:
>> >
>> >> Dan,
>> >>
>> >> The release-...rc13 branch is mostly something without purpose at this
>> >> point as far as I know.
>> >>
>> >> Our master branch has the latest release tags on it and represents the
>> >> code immediately following the last release.  It is at
>> >> '0.1.1-SNAPSHOT'.  If we had some critical need to kick out a pure bug
>> >> fix only 0.1.1 we could branch off there and apply the fixes and do
>> >> so.  When we finalize a release we merge the results to both master
>> >> and develop for this reason.  Now, during the release process and
>> >> afterward the develop branch just keeps on trucking along.
>> >>
>> >> So to your point about the roadmap that we definitely do need to
>> >> narrow in on.  We had a thread about what to do in 0.2.0 recently.
>> >> That brought up some good things, resulted in some JIRAs, etc..  I
>> >> plan to send an email out in a few that outlines a proposal for 0.2.0
>> >> and 0.3.0 based on reviewing all tickets and such today.
>> >>
>> >> The previous email about versioning describes a bit of the challenge
>> >> we face with ever really having much likelihood of a patch/incremental
>> >> release given the intent to adhere to semver at this stage.  Not a big
>> >> thing - just a thing.  But if we want to or need to we definitely can
>> >> so that is the key point.
>> >>
>> >> Thanks
>> >> Joe
>> >>
>> >> On Mon, Jun 1, 2015 at 11:00 AM, Dan Bress <db...@onyxconsults.com>
>> >> wrote:
>> >> > Aldrin,
>> >> >    I agree that a roadmap of features/bug fixes and future versions
>> >> would help (me) understand the path forward.
>> >> >
>> >> >     Do we anticipate our next release will be a bug fix release(0.1.1)
>> >> or a feature release(0.2.0) ?
>> >> >
>> >> >     Is there any reason we cannot work towards both of these releases
>> >> simultaneously?
>> >> >
>> >> >     If we decide to do a bug fix release, in which branch in git will
>> >> those changes be made?
>> >> >        - It feels like these changes would need to be done in a
>> >> separate, so as not to include the 0.2.0 features that people may be
>> >> working on.
>> >> >
>> >> > Dan Bress
>> >> > Software Engineer
>> >> > ONYX Consulting Services
>> >> >
>> >> > ________________________________________
>> >> > From: Aldrin Piri <al...@gmail.com>
>> >> > Sent: Sunday, May 31, 2015 10:44 AM
>> >> > To: dev@nifi.incubator.apache.org
>> >> > Subject: Re: Distinguishing between 0.2.0 vs 0.1.1 ?
>> >> >
>> >> > Good questions and points of discussion.
>> >> >
>> >> > I don't believe we have a clear path for handling this particular
>> >> > distinction, and would advocate for the community to devise a roadmap
>> >> (our
>> >> > newly allocated Wiki would be a prime candidate).  We had a request
>> for
>> >> > features to tackle moving forward and received a lot of great
>> feedback.
>> >> > Would like to see maybe reviving that thread and figuring out a
>> consensus
>> >> > for the best path forward.  The things that are in 0.2.0 will likely
>> need
>> >> > some considerable planning and design, so creating associated pages
>> for
>> >> the
>> >> > big features so we can hash that out, reference, and discuss would
>> >> provide
>> >> > a nice, collaborative space to help make those notions more concrete.
>> >> >
>> >> > To that end, I think most tickets that provide these quick shots of
>> >> > functionality and fixes are apt for another 0.1.x release in lieu of
>> the
>> >> > 0.2.0.   As far as your concerns from branching, I think git actually
>> >> buys
>> >> > you a lot from this standpoint with its (relatively) easy branch
>> >> management
>> >> > and rebasing to keep branches good to go.  To that end, develop is
>> still
>> >> > the source for branches, however there may be logistics on when and
>> how
>> >> > that is merged depending on scope.
>> >> >
>> >> > Not sure I completely follow the point about the release branch you
>> >> > mention, although I think that may just be a remnant of the last
>> release
>> >> > process.  The appropriate version is captured as a tag as I would
>> >> > anticipate.
>> >> >
>> >> > On Fri, May 29, 2015 at 8:55 AM, Dan Bress <db...@onyxconsults.com>
>> >> wrote:
>> >> >
>> >> >> Hi,
>> >> >>
>> >> >> Joe recently brought up the idea of thinking about what new features
>> go
>> >> in
>> >> >> 0.2.0 and what bug fixes go in 0.1.1. Did we make a decision on
>> that? I
>> >> >> bring it up because I could see three tickets being fixed/released
>> >> >> (quickly) in 0.1.1 (NIFI-633, NIFI-632, NIFI-638).
>> >> >>
>> >> >>
>> >> >> If we decide to do an 0.1.1, did we decide how that gets handled
>> from a
>> >> >> git/branching point of view?  Currently develop is labeled
>> >> >> '0.1.1-SNAPSHOT', and so is release-nifi-0.1.0-rc13<
>> >> >>
>> https://github.com/apache/incubator-nifi/tree/release-nifi-0.1.0-rc13>.
>> >> >>
>> >> >>
>> >> >> So where would 0.1.1 fixes go, and where would 0.2.0 features go?
>> >> >>
>> >> >>
>> >> >>
>> >> >> Dan Bress
>> >> >> Software Engineer
>> >> >> ONYX Consulting Services
>> >> >>
>> >>
>>

Re: Distinguishing between 0.2.0 vs 0.1.1 ?

[Tony Kurc <tr...@gmail.com>]

It sounds like it was unintentional. FWIW The other releases also had an
RC# tacked on the tag.

On Wed, Jun 3, 2015 at 10:48 PM, Joe Witt <jo...@gmail.com> wrote:

> Tony
>
> I have not confirmed this but what I would guess happened is a mistake
> during the release process.  If you look here
> http://nifi.incubator.apache.org/release-guide.html it outlines the
> proper responses for the questions maven asks.
>
> I think the wrong version name was used specifically for this question:
>
> "What is the release version for "Apache NiFi"? (org.apache.nifi:nifi)
> 0.0.1-incubating: :"
>
> The only one that requires manual entry is this one:
>
> "What is SCM release tag or label for "Apache NiFi"?
> (org.apache.nifi:nifi) nifi-0.0.1-incubating: :"
>
> Mark P: Can you confirm if this mistake was possibly made?  That is
> the only way I can see how this would have ended up in the build like
> that.
>
> Thanks
> Joe
>
> On Wed, Jun 3, 2015 at 10:38 PM, Tony Kurc <tr...@gmail.com> wrote:
> > Speaking of which, I'm a bit confused about the tags in git. Why is
> there a
> > RC13 on the recent release?
> >
> > On Wed, Jun 3, 2015 at 10:12 PM, Joe Witt <jo...@gmail.com> wrote:
> >
> >> Dan,
> >>
> >> The release-...rc13 branch is mostly something without purpose at this
> >> point as far as I know.
> >>
> >> Our master branch has the latest release tags on it and represents the
> >> code immediately following the last release.  It is at
> >> '0.1.1-SNAPSHOT'.  If we had some critical need to kick out a pure bug
> >> fix only 0.1.1 we could branch off there and apply the fixes and do
> >> so.  When we finalize a release we merge the results to both master
> >> and develop for this reason.  Now, during the release process and
> >> afterward the develop branch just keeps on trucking along.
> >>
> >> So to your point about the roadmap that we definitely do need to
> >> narrow in on.  We had a thread about what to do in 0.2.0 recently.
> >> That brought up some good things, resulted in some JIRAs, etc..  I
> >> plan to send an email out in a few that outlines a proposal for 0.2.0
> >> and 0.3.0 based on reviewing all tickets and such today.
> >>
> >> The previous email about versioning describes a bit of the challenge
> >> we face with ever really having much likelihood of a patch/incremental
> >> release given the intent to adhere to semver at this stage.  Not a big
> >> thing - just a thing.  But if we want to or need to we definitely can
> >> so that is the key point.
> >>
> >> Thanks
> >> Joe
> >>
> >> On Mon, Jun 1, 2015 at 11:00 AM, Dan Bress <db...@onyxconsults.com>
> >> wrote:
> >> > Aldrin,
> >> >    I agree that a roadmap of features/bug fixes and future versions
> >> would help (me) understand the path forward.
> >> >
> >> >     Do we anticipate our next release will be a bug fix release(0.1.1)
> >> or a feature release(0.2.0) ?
> >> >
> >> >     Is there any reason we cannot work towards both of these releases
> >> simultaneously?
> >> >
> >> >     If we decide to do a bug fix release, in which branch in git will
> >> those changes be made?
> >> >        - It feels like these changes would need to be done in a
> >> separate, so as not to include the 0.2.0 features that people may be
> >> working on.
> >> >
> >> > Dan Bress
> >> > Software Engineer
> >> > ONYX Consulting Services
> >> >
> >> > ________________________________________
> >> > From: Aldrin Piri <al...@gmail.com>
> >> > Sent: Sunday, May 31, 2015 10:44 AM
> >> > To: dev@nifi.incubator.apache.org
> >> > Subject: Re: Distinguishing between 0.2.0 vs 0.1.1 ?
> >> >
> >> > Good questions and points of discussion.
> >> >
> >> > I don't believe we have a clear path for handling this particular
> >> > distinction, and would advocate for the community to devise a roadmap
> >> (our
> >> > newly allocated Wiki would be a prime candidate).  We had a request
> for
> >> > features to tackle moving forward and received a lot of great
> feedback.
> >> > Would like to see maybe reviving that thread and figuring out a
> consensus
> >> > for the best path forward.  The things that are in 0.2.0 will likely
> need
> >> > some considerable planning and design, so creating associated pages
> for
> >> the
> >> > big features so we can hash that out, reference, and discuss would
> >> provide
> >> > a nice, collaborative space to help make those notions more concrete.
> >> >
> >> > To that end, I think most tickets that provide these quick shots of
> >> > functionality and fixes are apt for another 0.1.x release in lieu of
> the
> >> > 0.2.0.   As far as your concerns from branching, I think git actually
> >> buys
> >> > you a lot from this standpoint with its (relatively) easy branch
> >> management
> >> > and rebasing to keep branches good to go.  To that end, develop is
> still
> >> > the source for branches, however there may be logistics on when and
> how
> >> > that is merged depending on scope.
> >> >
> >> > Not sure I completely follow the point about the release branch you
> >> > mention, although I think that may just be a remnant of the last
> release
> >> > process.  The appropriate version is captured as a tag as I would
> >> > anticipate.
> >> >
> >> > On Fri, May 29, 2015 at 8:55 AM, Dan Bress <db...@onyxconsults.com>
> >> wrote:
> >> >
> >> >> Hi,
> >> >>
> >> >> Joe recently brought up the idea of thinking about what new features
> go
> >> in
> >> >> 0.2.0 and what bug fixes go in 0.1.1. Did we make a decision on
> that? I
> >> >> bring it up because I could see three tickets being fixed/released
> >> >> (quickly) in 0.1.1 (NIFI-633, NIFI-632, NIFI-638).
> >> >>
> >> >>
> >> >> If we decide to do an 0.1.1, did we decide how that gets handled
> from a
> >> >> git/branching point of view?  Currently develop is labeled
> >> >> '0.1.1-SNAPSHOT', and so is release-nifi-0.1.0-rc13<
> >> >>
> https://github.com/apache/incubator-nifi/tree/release-nifi-0.1.0-rc13>.
> >> >>
> >> >>
> >> >> So where would 0.1.1 fixes go, and where would 0.2.0 features go?
> >> >>
> >> >>
> >> >>
> >> >> Dan Bress
> >> >> Software Engineer
> >> >> ONYX Consulting Services
> >> >>
> >>
>

Re: Distinguishing between 0.2.0 vs 0.1.1 ?

[Joe Witt <jo...@gmail.com>]

Tony

I have not confirmed this but what I would guess happened is a mistake
during the release process.  If you look here
http://nifi.incubator.apache.org/release-guide.html it outlines the
proper responses for the questions maven asks.

I think the wrong version name was used specifically for this question:

"What is the release version for "Apache NiFi"? (org.apache.nifi:nifi)
0.0.1-incubating: :"

The only one that requires manual entry is this one:

"What is SCM release tag or label for "Apache NiFi"?
(org.apache.nifi:nifi) nifi-0.0.1-incubating: :"

Mark P: Can you confirm if this mistake was possibly made?  That is
the only way I can see how this would have ended up in the build like
that.

Thanks
Joe

On Wed, Jun 3, 2015 at 10:38 PM, Tony Kurc <tr...@gmail.com> wrote:
> Speaking of which, I'm a bit confused about the tags in git. Why is there a
> RC13 on the recent release?
>
> On Wed, Jun 3, 2015 at 10:12 PM, Joe Witt <jo...@gmail.com> wrote:
>
>> Dan,
>>
>> The release-...rc13 branch is mostly something without purpose at this
>> point as far as I know.
>>
>> Our master branch has the latest release tags on it and represents the
>> code immediately following the last release.  It is at
>> '0.1.1-SNAPSHOT'.  If we had some critical need to kick out a pure bug
>> fix only 0.1.1 we could branch off there and apply the fixes and do
>> so.  When we finalize a release we merge the results to both master
>> and develop for this reason.  Now, during the release process and
>> afterward the develop branch just keeps on trucking along.
>>
>> So to your point about the roadmap that we definitely do need to
>> narrow in on.  We had a thread about what to do in 0.2.0 recently.
>> That brought up some good things, resulted in some JIRAs, etc..  I
>> plan to send an email out in a few that outlines a proposal for 0.2.0
>> and 0.3.0 based on reviewing all tickets and such today.
>>
>> The previous email about versioning describes a bit of the challenge
>> we face with ever really having much likelihood of a patch/incremental
>> release given the intent to adhere to semver at this stage.  Not a big
>> thing - just a thing.  But if we want to or need to we definitely can
>> so that is the key point.
>>
>> Thanks
>> Joe
>>
>> On Mon, Jun 1, 2015 at 11:00 AM, Dan Bress <db...@onyxconsults.com>
>> wrote:
>> > Aldrin,
>> >    I agree that a roadmap of features/bug fixes and future versions
>> would help (me) understand the path forward.
>> >
>> >     Do we anticipate our next release will be a bug fix release(0.1.1)
>> or a feature release(0.2.0) ?
>> >
>> >     Is there any reason we cannot work towards both of these releases
>> simultaneously?
>> >
>> >     If we decide to do a bug fix release, in which branch in git will
>> those changes be made?
>> >        - It feels like these changes would need to be done in a
>> separate, so as not to include the 0.2.0 features that people may be
>> working on.
>> >
>> > Dan Bress
>> > Software Engineer
>> > ONYX Consulting Services
>> >
>> > ________________________________________
>> > From: Aldrin Piri <al...@gmail.com>
>> > Sent: Sunday, May 31, 2015 10:44 AM
>> > To: dev@nifi.incubator.apache.org
>> > Subject: Re: Distinguishing between 0.2.0 vs 0.1.1 ?
>> >
>> > Good questions and points of discussion.
>> >
>> > I don't believe we have a clear path for handling this particular
>> > distinction, and would advocate for the community to devise a roadmap
>> (our
>> > newly allocated Wiki would be a prime candidate).  We had a request for
>> > features to tackle moving forward and received a lot of great feedback.
>> > Would like to see maybe reviving that thread and figuring out a consensus
>> > for the best path forward.  The things that are in 0.2.0 will likely need
>> > some considerable planning and design, so creating associated pages for
>> the
>> > big features so we can hash that out, reference, and discuss would
>> provide
>> > a nice, collaborative space to help make those notions more concrete.
>> >
>> > To that end, I think most tickets that provide these quick shots of
>> > functionality and fixes are apt for another 0.1.x release in lieu of the
>> > 0.2.0.   As far as your concerns from branching, I think git actually
>> buys
>> > you a lot from this standpoint with its (relatively) easy branch
>> management
>> > and rebasing to keep branches good to go.  To that end, develop is still
>> > the source for branches, however there may be logistics on when and how
>> > that is merged depending on scope.
>> >
>> > Not sure I completely follow the point about the release branch you
>> > mention, although I think that may just be a remnant of the last release
>> > process.  The appropriate version is captured as a tag as I would
>> > anticipate.
>> >
>> > On Fri, May 29, 2015 at 8:55 AM, Dan Bress <db...@onyxconsults.com>
>> wrote:
>> >
>> >> Hi,
>> >>
>> >> Joe recently brought up the idea of thinking about what new features go
>> in
>> >> 0.2.0 and what bug fixes go in 0.1.1. Did we make a decision on that? I
>> >> bring it up because I could see three tickets being fixed/released
>> >> (quickly) in 0.1.1 (NIFI-633, NIFI-632, NIFI-638).
>> >>
>> >>
>> >> If we decide to do an 0.1.1, did we decide how that gets handled from a
>> >> git/branching point of view?  Currently develop is labeled
>> >> '0.1.1-SNAPSHOT', and so is release-nifi-0.1.0-rc13<
>> >> https://github.com/apache/incubator-nifi/tree/release-nifi-0.1.0-rc13>.
>> >>
>> >>
>> >> So where would 0.1.1 fixes go, and where would 0.2.0 features go?
>> >>
>> >>
>> >>
>> >> Dan Bress
>> >> Software Engineer
>> >> ONYX Consulting Services
>> >>
>>

Re: Distinguishing between 0.2.0 vs 0.1.1 ?

[Tony Kurc <tr...@gmail.com>]

Speaking of which, I'm a bit confused about the tags in git. Why is there a
RC13 on the recent release?

On Wed, Jun 3, 2015 at 10:12 PM, Joe Witt <jo...@gmail.com> wrote:

> Dan,
>
> The release-...rc13 branch is mostly something without purpose at this
> point as far as I know.
>
> Our master branch has the latest release tags on it and represents the
> code immediately following the last release.  It is at
> '0.1.1-SNAPSHOT'.  If we had some critical need to kick out a pure bug
> fix only 0.1.1 we could branch off there and apply the fixes and do
> so.  When we finalize a release we merge the results to both master
> and develop for this reason.  Now, during the release process and
> afterward the develop branch just keeps on trucking along.
>
> So to your point about the roadmap that we definitely do need to
> narrow in on.  We had a thread about what to do in 0.2.0 recently.
> That brought up some good things, resulted in some JIRAs, etc..  I
> plan to send an email out in a few that outlines a proposal for 0.2.0
> and 0.3.0 based on reviewing all tickets and such today.
>
> The previous email about versioning describes a bit of the challenge
> we face with ever really having much likelihood of a patch/incremental
> release given the intent to adhere to semver at this stage.  Not a big
> thing - just a thing.  But if we want to or need to we definitely can
> so that is the key point.
>
> Thanks
> Joe
>
> On Mon, Jun 1, 2015 at 11:00 AM, Dan Bress <db...@onyxconsults.com>
> wrote:
> > Aldrin,
> >    I agree that a roadmap of features/bug fixes and future versions
> would help (me) understand the path forward.
> >
> >     Do we anticipate our next release will be a bug fix release(0.1.1)
> or a feature release(0.2.0) ?
> >
> >     Is there any reason we cannot work towards both of these releases
> simultaneously?
> >
> >     If we decide to do a bug fix release, in which branch in git will
> those changes be made?
> >        - It feels like these changes would need to be done in a
> separate, so as not to include the 0.2.0 features that people may be
> working on.
> >
> > Dan Bress
> > Software Engineer
> > ONYX Consulting Services
> >
> > ________________________________________
> > From: Aldrin Piri <al...@gmail.com>
> > Sent: Sunday, May 31, 2015 10:44 AM
> > To: dev@nifi.incubator.apache.org
> > Subject: Re: Distinguishing between 0.2.0 vs 0.1.1 ?
> >
> > Good questions and points of discussion.
> >
> > I don't believe we have a clear path for handling this particular
> > distinction, and would advocate for the community to devise a roadmap
> (our
> > newly allocated Wiki would be a prime candidate).  We had a request for
> > features to tackle moving forward and received a lot of great feedback.
> > Would like to see maybe reviving that thread and figuring out a consensus
> > for the best path forward.  The things that are in 0.2.0 will likely need
> > some considerable planning and design, so creating associated pages for
> the
> > big features so we can hash that out, reference, and discuss would
> provide
> > a nice, collaborative space to help make those notions more concrete.
> >
> > To that end, I think most tickets that provide these quick shots of
> > functionality and fixes are apt for another 0.1.x release in lieu of the
> > 0.2.0.   As far as your concerns from branching, I think git actually
> buys
> > you a lot from this standpoint with its (relatively) easy branch
> management
> > and rebasing to keep branches good to go.  To that end, develop is still
> > the source for branches, however there may be logistics on when and how
> > that is merged depending on scope.
> >
> > Not sure I completely follow the point about the release branch you
> > mention, although I think that may just be a remnant of the last release
> > process.  The appropriate version is captured as a tag as I would
> > anticipate.
> >
> > On Fri, May 29, 2015 at 8:55 AM, Dan Bress <db...@onyxconsults.com>
> wrote:
> >
> >> Hi,
> >>
> >> Joe recently brought up the idea of thinking about what new features go
> in
> >> 0.2.0 and what bug fixes go in 0.1.1. Did we make a decision on that? I
> >> bring it up because I could see three tickets being fixed/released
> >> (quickly) in 0.1.1 (NIFI-633, NIFI-632, NIFI-638).
> >>
> >>
> >> If we decide to do an 0.1.1, did we decide how that gets handled from a
> >> git/branching point of view?  Currently develop is labeled
> >> '0.1.1-SNAPSHOT', and so is release-nifi-0.1.0-rc13<
> >> https://github.com/apache/incubator-nifi/tree/release-nifi-0.1.0-rc13>.
> >>
> >>
> >> So where would 0.1.1 fixes go, and where would 0.2.0 features go?
> >>
> >>
> >>
> >> Dan Bress
> >> Software Engineer
> >> ONYX Consulting Services
> >>
>

Re: Distinguishing between 0.2.0 vs 0.1.1 ?

[Joe Witt <jo...@gmail.com>]

Dan,

The release-...rc13 branch is mostly something without purpose at this
point as far as I know.

Our master branch has the latest release tags on it and represents the
code immediately following the last release.  It is at
'0.1.1-SNAPSHOT'.  If we had some critical need to kick out a pure bug
fix only 0.1.1 we could branch off there and apply the fixes and do
so.  When we finalize a release we merge the results to both master
and develop for this reason.  Now, during the release process and
afterward the develop branch just keeps on trucking along.

So to your point about the roadmap that we definitely do need to
narrow in on.  We had a thread about what to do in 0.2.0 recently.
That brought up some good things, resulted in some JIRAs, etc..  I
plan to send an email out in a few that outlines a proposal for 0.2.0
and 0.3.0 based on reviewing all tickets and such today.

The previous email about versioning describes a bit of the challenge
we face with ever really having much likelihood of a patch/incremental
release given the intent to adhere to semver at this stage.  Not a big
thing - just a thing.  But if we want to or need to we definitely can
so that is the key point.

Thanks
Joe

On Mon, Jun 1, 2015 at 11:00 AM, Dan Bress <db...@onyxconsults.com> wrote:
> Aldrin,
>    I agree that a roadmap of features/bug fixes and future versions would help (me) understand the path forward.
>
>     Do we anticipate our next release will be a bug fix release(0.1.1) or a feature release(0.2.0) ?
>
>     Is there any reason we cannot work towards both of these releases simultaneously?
>
>     If we decide to do a bug fix release, in which branch in git will those changes be made?
>        - It feels like these changes would need to be done in a separate, so as not to include the 0.2.0 features that people may be working on.
>
> Dan Bress
> Software Engineer
> ONYX Consulting Services
>
> ________________________________________
> From: Aldrin Piri <al...@gmail.com>
> Sent: Sunday, May 31, 2015 10:44 AM
> To: dev@nifi.incubator.apache.org
> Subject: Re: Distinguishing between 0.2.0 vs 0.1.1 ?
>
> Good questions and points of discussion.
>
> I don't believe we have a clear path for handling this particular
> distinction, and would advocate for the community to devise a roadmap (our
> newly allocated Wiki would be a prime candidate).  We had a request for
> features to tackle moving forward and received a lot of great feedback.
> Would like to see maybe reviving that thread and figuring out a consensus
> for the best path forward.  The things that are in 0.2.0 will likely need
> some considerable planning and design, so creating associated pages for the
> big features so we can hash that out, reference, and discuss would provide
> a nice, collaborative space to help make those notions more concrete.
>
> To that end, I think most tickets that provide these quick shots of
> functionality and fixes are apt for another 0.1.x release in lieu of the
> 0.2.0.   As far as your concerns from branching, I think git actually buys
> you a lot from this standpoint with its (relatively) easy branch management
> and rebasing to keep branches good to go.  To that end, develop is still
> the source for branches, however there may be logistics on when and how
> that is merged depending on scope.
>
> Not sure I completely follow the point about the release branch you
> mention, although I think that may just be a remnant of the last release
> process.  The appropriate version is captured as a tag as I would
> anticipate.
>
> On Fri, May 29, 2015 at 8:55 AM, Dan Bress <db...@onyxconsults.com> wrote:
>
>> Hi,
>>
>> Joe recently brought up the idea of thinking about what new features go in
>> 0.2.0 and what bug fixes go in 0.1.1. Did we make a decision on that? I
>> bring it up because I could see three tickets being fixed/released
>> (quickly) in 0.1.1 (NIFI-633, NIFI-632, NIFI-638).
>>
>>
>> If we decide to do an 0.1.1, did we decide how that gets handled from a
>> git/branching point of view?  Currently develop is labeled
>> '0.1.1-SNAPSHOT', and so is release-nifi-0.1.0-rc13<
>> https://github.com/apache/incubator-nifi/tree/release-nifi-0.1.0-rc13>.
>>
>>
>> So where would 0.1.1 fixes go, and where would 0.2.0 features go?
>>
>>
>>
>> Dan Bress
>> Software Engineer
>> ONYX Consulting Services
>>

Re: Distinguishing between 0.2.0 vs 0.1.1 ?

[Dan Bress <db...@onyxconsults.com>]

Aldrin,
   I agree that a roadmap of features/bug fixes and future versions would help (me) understand the path forward.
   
    Do we anticipate our next release will be a bug fix release(0.1.1) or a feature release(0.2.0) ?

    Is there any reason we cannot work towards both of these releases simultaneously?

    If we decide to do a bug fix release, in which branch in git will those changes be made?
       - It feels like these changes would need to be done in a separate, so as not to include the 0.2.0 features that people may be working on.

Dan Bress
Software Engineer
ONYX Consulting Services

________________________________________
From: Aldrin Piri <al...@gmail.com>
Sent: Sunday, May 31, 2015 10:44 AM
To: dev@nifi.incubator.apache.org
Subject: Re: Distinguishing between 0.2.0 vs 0.1.1 ?

Good questions and points of discussion.

I don't believe we have a clear path for handling this particular
distinction, and would advocate for the community to devise a roadmap (our
newly allocated Wiki would be a prime candidate).  We had a request for
features to tackle moving forward and received a lot of great feedback.
Would like to see maybe reviving that thread and figuring out a consensus
for the best path forward.  The things that are in 0.2.0 will likely need
some considerable planning and design, so creating associated pages for the
big features so we can hash that out, reference, and discuss would provide
a nice, collaborative space to help make those notions more concrete.

To that end, I think most tickets that provide these quick shots of
functionality and fixes are apt for another 0.1.x release in lieu of the
0.2.0.   As far as your concerns from branching, I think git actually buys
you a lot from this standpoint with its (relatively) easy branch management
and rebasing to keep branches good to go.  To that end, develop is still
the source for branches, however there may be logistics on when and how
that is merged depending on scope.

Not sure I completely follow the point about the release branch you
mention, although I think that may just be a remnant of the last release
process.  The appropriate version is captured as a tag as I would
anticipate.

On Fri, May 29, 2015 at 8:55 AM, Dan Bress <db...@onyxconsults.com> wrote:

> Hi,
>
> Joe recently brought up the idea of thinking about what new features go in
> 0.2.0 and what bug fixes go in 0.1.1. Did we make a decision on that? I
> bring it up because I could see three tickets being fixed/released
> (quickly) in 0.1.1 (NIFI-633, NIFI-632, NIFI-638).
>
>
> If we decide to do an 0.1.1, did we decide how that gets handled from a
> git/branching point of view?  Currently develop is labeled
> '0.1.1-SNAPSHOT', and so is release-nifi-0.1.0-rc13<
> https://github.com/apache/incubator-nifi/tree/release-nifi-0.1.0-rc13>.
>
>
> So where would 0.1.1 fixes go, and where would 0.2.0 features go?
>
>
>
> Dan Bress
> Software Engineer
> ONYX Consulting Services
>

Re: Distinguishing between 0.2.0 vs 0.1.1 ?

[Aldrin Piri <al...@gmail.com>]

Good questions and points of discussion.

I don't believe we have a clear path for handling this particular
distinction, and would advocate for the community to devise a roadmap (our
newly allocated Wiki would be a prime candidate).  We had a request for
features to tackle moving forward and received a lot of great feedback.
Would like to see maybe reviving that thread and figuring out a consensus
for the best path forward.  The things that are in 0.2.0 will likely need
some considerable planning and design, so creating associated pages for the
big features so we can hash that out, reference, and discuss would provide
a nice, collaborative space to help make those notions more concrete.

To that end, I think most tickets that provide these quick shots of
functionality and fixes are apt for another 0.1.x release in lieu of the
0.2.0.   As far as your concerns from branching, I think git actually buys
you a lot from this standpoint with its (relatively) easy branch management
and rebasing to keep branches good to go.  To that end, develop is still
the source for branches, however there may be logistics on when and how
that is merged depending on scope.

Not sure I completely follow the point about the release branch you
mention, although I think that may just be a remnant of the last release
process.  The appropriate version is captured as a tag as I would
anticipate.

On Fri, May 29, 2015 at 8:55 AM, Dan Bress <db...@onyxconsults.com> wrote:

> Hi,
>
> Joe recently brought up the idea of thinking about what new features go in
> 0.2.0 and what bug fixes go in 0.1.1. Did we make a decision on that? I
> bring it up because I could see three tickets being fixed/released
> (quickly) in 0.1.1 (NIFI-633, NIFI-632, NIFI-638).
>
>
> If we decide to do an 0.1.1, did we decide how that gets handled from a
> git/branching point of view?  Currently develop is labeled
> '0.1.1-SNAPSHOT', and so is release-nifi-0.1.0-rc13<
> https://github.com/apache/incubator-nifi/tree/release-nifi-0.1.0-rc13>.
>
>
> So where would 0.1.1 fixes go, and where would 0.2.0 features go?
>
>
>
> Dan Bress
> Software Engineer
> ONYX Consulting Services
>