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" <[email protected]> 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 <[email protected]> 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" <[email protected]> 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 <[email protected]> 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 <[email protected]> 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" <[email protected]> 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? > >> > > > >> > > >> >
