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 >> >> >>
