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