I agree with all those points, but a big +1 to this: > By making any release (incremental, major, or minor) we should be > saying that it is in a mature state and we should certainly be saying > there is no known "loss of capability or risk to their data". For the > examples you provide I believe those fall under the guidance that > states we would backport and produce a release. > > Users will never uptake new versions as fast as we'd like. That is > why we should focus on producing higher and higher quality releases > and why we should focus on making the process of upgrading as smooth > as possible.
Andy LoPresto alopre...@apache.org alopresto.apa...@gmail.com PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 > On Jun 16, 2016, at 1:14 PM, Joe Witt <joe.w...@gmail.com> wrote: > > JoeS, > > Understood. Some responses for the points you are raising. > > --- > "At a minimum, everything needed to upgrade from X to Y needs to be > explicitly covered in a migration document" > > Agreed. That is the intent of this document [1] primarily. There is > also useful information related to how the community has discussed > handling such things here [2] and here [3]. > > --- > "At a minimum, everything needed to upgrade from X to Y needs to > be...where possible and practical...simplified by tools or scripts" > > Agreed. That I think is well reflected in JIRAs and feature proposals > which can be disruptive in nature and also in techniques that have > been adopted for some time. For some concrete examples of the > commitment to easing and promoting upgrades: > > 1) The old flow configuration is designed to be automatically > converted/honored on startup > 2) The old authorization file configuration is automatically converted > to the new policies model on startup. > 3) Placement/dimensions of components on the old flow configuration > are automatically scaled to look nice in the new UI. > 4) Key features such as site to site and flow file repository have > been build to store and honor versions so that new versions can read > and port them. This will also occur with the flow configuration > itself going forward. > > --- > "I think any change to reduce support for 0.x should depend on first > reaching a mature state with 1.x" > > By making any release (incremental, major, or minor) we should be > saying that it is in a mature state and we should certainly be saying > there is no known "loss of capability or risk to their data". For the > examples you provide I believe those fall under the guidance that > states we would backport and produce a release. > > Users will never uptake new versions as fast as we'd like. That is > why we should focus on producing higher and higher quality releases > and why we should focus on making the process of upgrading as smooth > as possible. > > [1] https://cwiki.apache.org/confluence/display/NIFI/Migration+Guidance > [2] https://cwiki.apache.org/confluence/display/NIFI/Upgrading+NiFi > [3] https://cwiki.apache.org/confluence/display/NIFI/Version+Scheme > [4] > https://cwiki.apache.org/confluence/display/NIFI/Git+Branching+and+Release+Line+Management > > Thanks > Joe > > 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? >>>>>>>> >>>>>>> >>>>>> >>>> >>>
signature.asc
Description: Message signed with OpenPGP using GPGMail
