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