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