Hi Ryan, That sounds like a separate discussion the community should weigh in on. Right now, the release management process is fairly extensive and takes a few days of manual work to perform. In addition, releases need to be voted on by the community in order to be released, so this is an effort for community members as well.
I’m not opposed to improving our RM process to make this work easier, but it’s not as simple as just cutting a release more frequently at this point in time. If you so desire, you can always checkout the current master or specific feature branches. It’s possible we could do something like a nightly tag, but officially releasing that through the Apache process is probably not doable in the near-term. The semantic versioning is also an issue, because 1.6.x releases are supposed to be bug fixes only, not feature releases [1]. > For the public API the Apache NiFi project aims to follow versioning > principles as described at Semantic Versioning 2.0.0 <http://semver.org/> > Consider the following scenarios in the context of the most recent 'example' > release being 0.0.1 and with the understanding that these are about the > public API as defined above. > For releases which are comprised solely of bug fixes or non-feature > introducing or enhancing changes that requires only a 'patch' version bump > (the Z part in X.Y.Z). So the next release then is 0.0.2. > For releases which include backward compatible changes to introduce feature > enhancements or new features that requires a 'minor' version change and the > 'patch' version resets to '0' (the Y part in X.Y.0). So the next release > then is 0.1.0. A 'minor' version change is also required for any change that > could result in an existing flow becoming invalid, such as the addition of a > required property with no default or the addition of a relationship, or the > removal of a property or relationship. Note: it is NOT acceptable in a > 'minor' version to change anything that can result in an existing flow > behaving differently (other than a component becoming invalid). Doing so > would fundamentally alter the way in which organizations process data without > them realizing it. > For releases which include non-backward compatible changes or changes deemed > so substantive by the community that it is considered a 'major' version > change and the minor and patch versions reset to '0' (the X part in X.0.0). > So the next release then is 1.0.0. > After a release occurs the 'patch' version will be automatically adjusted by > maven without the release manager doing anything special. So rarely will > this value need to be manually set. In the event of a 'major' or 'minor' > bump though the entire relevant source tree will need to be adjusted. [1] https://cwiki.apache.org/confluence/display/NIFI/Version+Scheme+and+API+Compatibility <https://cwiki.apache.org/confluence/display/NIFI/Version+Scheme+and+API+Compatibility> Andy LoPresto [email protected] [email protected] PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 > On Jul 9, 2018, at 12:11 PM, Ryan Hendrickson > <[email protected]> wrote: > > As a user of NiFi, and someone converting things to use more standard > processors, vs writing custom ones, I'd prefer smaller releases, or > possible a release that only updates Processors with the bug fixes and > improvements that went into them vs having to diff the configuration files > each upgrade. The bigger releases, like 1.6.0 (163 updates), and 1.7.0 > (191 updates) are great, but the waiting game for fixes to go into a > release seems long. I'd love a weekly release, or even just know that once > a month there will be a 1.6.x release coming out with updates to processors. > > That said, I can't wait for this fix, slated for 1.8.0: > https://issues.apache.org/jira/browse/NIFI-5334 (GetMongo should pass > along NiFi FlowFile Attributes), love to see it in a 1.7.1. > > Ryan > > On Fri, Jul 6, 2018 at 10:55 AM Mike Thomsen <[email protected]> wrote: > >> Aldrin and I got some Docker improvements in lately that might be good to >> throw in as well. They can definitely wait until 1.8 if everyone wants to >> KISS this release, but they could also add some real value for the docker >> users too. >> >> On Fri, Jul 6, 2018 at 1:31 AM V, Prashanth (Nokia - IN/Bangalore) < >> [email protected]> wrote: >> >>> Thanks Andy.. +1 for 1.7.1 release. >>> >>> Thanks & Regards, >>> Prashanth >>> >>> From: Andy LoPresto [mailto:[email protected]] >>> Sent: Friday, July 06, 2018 1:34 AM >>> To: [email protected] >>> Subject: Re: [discuss] should we do a nifi 1.7.1 release? >>> >>> I’m working on the wildcard cert issue and would be able to put that >> along >>> with some other minor fixes into a 1.7.1 release. >>> >>> Andy LoPresto >>> [email protected]<mailto:[email protected]> >>> [email protected]<mailto:[email protected]> >>> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 >>> >>> On Jul 5, 2018, at 11:01 AM, Robert R. Bruno <[email protected]<mailto: >>> [email protected]>> wrote: >>> >>> +1 as well. Any chance of this one as well? >>> >>> https://issues.apache.org/jira/browse/NIFI-5316 >>> >>> On Thu, Jul 5, 2018, 11:33 Mark Bean <[email protected]<mailto: >>> [email protected]>> wrote: >>> >>> >>> +1 for a 1.7.1 release if it contains a fix for NIFI-5368 [1]. This bug >> is >>> breaking multiple unit tests on custom processors. >>> >>> [1] https://issues.apache.org/jira/browse/NIFI-5368 >>> >>> >>> >>> On Thu, Jul 5, 2018 at 12:23 PM Joe Witt <[email protected]<mailto: >>> [email protected]>> wrote: >>> >>> >>> team, >>> >>> Wanted to kick off a thread to suggest we do a nifi 1.7.1 release. It >>> sounds like we might have an issue handling wildcard certs in 1.7.0 >>> [1] and it was reported again in an email today i think. Also, if >>> this one is deemed legit it seems worth sorting out [2]. I'd imagine >>> there are a few other bug fixes as well we can pull in. >>> >>> >>> [1] https://issues.apache.org/jira/browse/NIFI-5370 >>> [2] https://issues.apache.org/jira/browse/NIFI-5377 >>> >>> Thanks >>> Joe >>> >>> >>> >>
signature.asc
Description: Message signed with OpenPGP using GPGMail
