Sorry, put this in the wrong thread... In another thread, I put forth the recommendation of a 0.7.1 release, for features that don't make it in 0.7.0, but were intended to (to speed along the 0.7.0 release).
As a consumer of NIFI, I still like that idea. Not being part of the dev team, but assuming based on their track record, I'm simply expecting an 0.7.1 release at some point in time. We're leaving room in our schedule to accommodate another release, however it's my hope it isn't a 'critical' release. If you look at the release history, it's clear that quickly after an 0.x release there's a follow-up 0.x.1 release, whether to fix critical bugs or add features. (Assuming the dir create date reflects the release date) [DIR] 0.4.0/ 2015-12-11 22:25 - [DIR] 0.4.1/ 2015-12-22 15:59 - 11 days after [DIR] 0.5.0/ 2016-02-17 00:56 - [DIR] 0.5.1/ 2016-02-27 03:06 - 10 days after [DIR] 0.6.0/ 2016-03-27 03:03 - [DIR] 0.6.1/ 2016-04-16 19:06 - 20 days after Outside of the 0.7.1 release, I thought the target for 1.0.0 was end-of-summer. That's about 2 months away. Same release gap as 0.6.1 to 0.7.0. Even if that were mid-fall, based on everything that 1.0.0 is said to be, that's a fantastic target date! Ryan On Wed, Jun 15, 2016 at 3:59 PM, Joe Skora <jsk...@gmail.com> wrote: > I think any change to reduce support for 0.x should depend on first > reaching a mature state with 1.x. Only after the new release is stable can > 0.x users upgrade to 1.x without loss of capability or risk to their data. > > I don't think the guidance needs significant changes, but from an > enterprise use perspective this line concerns. > > > When the release line on master has no releases we will back port... > > I'd prefer something along the lines of this. > > > Until the release line on master has reached a mature release we will > back > > port... > > > > Once an enterprise commits to a deployment of something like NiFi, changes > are expensive and disruptive. At a minimum, everything needed to upgrade > from X to Y needs to be explicitly covered in a migration document, and > where possible and practical simplified by tools or scripts. I'm not sure > how to put that commitment in writing since it can't be an absolute, but a > statement to that effect seems missing in the guidance. > > On Wed, Jun 15, 2016 at 3:22 PM, Tony Kurc <trk...@gmail.com> wrote: > > > Yes, I think we need to probably tighten the language to take as much > > inference (and hence misunderstanding) out as possible. > > On Jun 15, 2016 5:59 PM, "Joe Witt" <joe.w...@gmail.com> wrote: > > > > > <Pulling this away from the 0.7 release efforts thread> > > > > > > > > > Tony, Joe, > > > > > > It sounds as though you would like to propose a change to this [1] > > > release line management guidance that we generated as a result of the > > > various discussions. > > > > > > Can you please propose some changes to that guidance? > > > > > > Of course, we must always work to support easy migration for > > > developers and users any time we move minor or major releases out. > > > > > > [1] > > > > > > https://cwiki.apache.org/confluence/display/NIFI/Git+Branching+and+Release+Line+Management > > > > > > Thanks > > > Joe > > > > > > On Wed, Jun 15, 2016 at 11:14 AM, Tony Kurc <trk...@gmail.com> wrote: > > > > I remember the thread, but it seems I need to reread the thread - > > > honestly > > > > the comment did take me by surprise, I think we may have used a few > > terms > > > > that were left open to interpretation. > > > > On Jun 15, 2016 5:06 PM, "Joe Skora" <jsk...@gmail.com> wrote: > > > > > > > >> I agree with Tony on this. > > > >> > > > >> The point of release branching, etc. is to make it possible to > > maintain > > > an > > > >> older version while building the newer version. Yes, it is a > > nuisance, > > > but > > > >> not nearly as much as a new version is for users if it is has > > > significant > > > >> changes and/or bugs. Except in cases where there is a captive user > > > base, > > > >> failure to maintain the prior version while perfecting the latest > and > > > >> greatest can be a fatal decision. > > > >> > > > >> The 0.x version does have shortcomings, but with the amount of the > > > back-end > > > >> and front-end that has completely redesigned, I am concerned that a > > > >> stagnant 0.x will result is a loss of users. The transition from > 0.x > > to > > > >> 1.x will not be easy for most users. In many ways, transitioning to > > 1.x > > > >> will be like implementing a whole new system which would cause most > > > >> organizations I've worked to revisit their system choice to see what > > > other > > > >> solutions might exist for their use cases. > > > >> > > > >> On Tue, Jun 14, 2016 at 7:11 PM, Andre <andre-li...@fucs.org> > wrote: > > > >> > > > >> > Tony, > > > >> > > > > >> > I second Joe's comments as well. > > > >> > > > > >> > Since the early discussions about the branching model I have been > > > under > > > >> the > > > >> > total impression that once 1.0 is released, 0.x would become > support > > > only > > > >> > and updates restricted to critical issues (security & data-loss > > > >> > break-fixes). > > > >> > > > > >> > This is not to say that a NPE or a 100% CPU issue shouldn't be > > > >> backported, > > > >> > but I would imagine the effort to port to 0.x should be driven by > > the > > > >> > contributor rather than the merger (as it is being done atm). > > > >> > > > > >> > On Wed, Jun 15, 2016 at 8:13 AM, Joe Witt <joe.w...@gmail.com> > > wrote: > > > >> > > > > >> > > According to the discussion we had about the management of the > > > release > > > >> > > lines there would only be incremental releases when something > was > > > >> > critical > > > >> > > enough (security or data loss). And, if someone really wanted > > > needed a > > > >> > > minor release they could initiate and do that as well. But as > far > > > as > > > >> > > continued feature development and focus it would shift to 1.0. > > > >> > > > > > >> > > So emphasis moves to new major line but those staying on the old > > > major > > > >> > can > > > >> > > still have options as well. > > > >> > > On Jun 14, 2016 5:31 PM, "Tony Kurc" <trk...@gmail.com> wrote: > > > >> > > > > > >> > > Joe, for some reason, my mental image was that I expected we'd > > keep > > > >> > > releasing new 0.x minor releases for a while along with 1.x. > > > >> > > > > > >> > > Is that everyone else's expectations? > > > >> > > > > > >> > > > > >> > > > > > >
