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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]>
>> >> 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 <[email protected]>
>> >> > Sent: Sunday, May 31, 2015 10:44 AM
>> >> > To: [email protected]
>> >> > 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 <[email protected]>
>> >> 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
>> >> >>
>> >>
>>
