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