Otto, Good points. Generally, I think we don’t need two PRs. The committer should just merge to main and then cherry-pick to the support/nifi-1.x branch.
In the event that there are conflicts, my suggestion would be: The committer should make a reasonable effort to resolve the issue. I.e., if it doesn’t apply cleanly but it’s a 3-line change that can just be copied from one branch and pasted to the other, then go ahead and make that change. If the PR is substantial enough that it cannot be easily merged, the committer should notify the contributor that it cannot be merged to the 1.x branch. In that event, it would be up to the committer (or someone else) to submit a new PR for the 1.x baseline. If that doesn’t happen, the fix would be merged only into the 2.x baseline. I agree it’s probably a good idea, if opening a PR targeted explicitly to the 1.x baseline to note that in the title. Perhaps denoting "[1.x only]” or something along those lines. But GitHub should denote which upstream branch it’s intended to be merged to. So it will be up to the dilligence of committers to ensure that we’re merging to the right branch. Thanks -Mark On Feb 11, 2023, at 11:16 AM, Otto Fowler <ottobackwa...@gmail.com> wrote: Thanks Mark, Can you give an example of best practices cherry picking? This cherry picked commit ( and any other re-work required to make it work ) will be a new PR then? Or is that only if it doesn’t go in clean? Contributor: - Pull Request Committer: - Merge - Cherry Pick to new PR branch off of support/nifi-1.x - possible fixups - push a new PR Should the support/nifi-1.x PRs have a standard name format WRT the original? Should the name be the same as the subject of the other, or should it be the PR#? From: Mark Payne <marka...@hotmail.com<mailto:marka...@hotmail.com>> <marka...@hotmail.com<mailto:marka...@hotmail.com>> Reply: dev@nifi.apache.org<mailto:dev@nifi.apache.org> <dev@nifi.apache.org<mailto:dev@nifi.apache.org>> <dev@nifi.apache.org<mailto:dev@nifi.apache.org>> Date: February 10, 2023 at 11:51:28 To: dev@nifi.apache.org<mailto:dev@nifi.apache.org> <dev@nifi.apache.org<mailto:dev@nifi.apache.org>> <dev@nifi.apache.org<mailto:dev@nifi.apache.org>> Subject: Re: [discuss] NiFi 1.20 and NiFi 2.0 Thanks Joe! So at this point, we now have the 1.x and the 2.x line diverging. As a result, we will want to ensure that we keep the 1.x line up-to-date with any bug fixes. Trying to cherry-pick over just the necessary bug fixes for a release down the road has the potential to be a nightmare, since some PRs may not apply cleanly. In order to avoid this: committers please ensure that for any bug fixes, if you merge to the “main” branch that you also cherry-pick the commit to the “support/nifi-1.x” branch. If you’ve not dealt with support branches in the past, there’s one small gotcha, as the branch name has a slash (/) in it. So to checkout the support branch, you’ll use: git checkout origin/support/nifi-1.x And not just “git checkout support/nifi-1.x” Then, you can create a local branch: git checkout -b support/nifi-1.x And after cherry-picking the necessary commits, you can push: git push -u origin support/nifi-1.x This will help to ensure that we keep a clean support branch so that we’re able to make a release any time if the need arises, which will include all of the necessary bug fixes. Thanks -Mark On Feb 9, 2023, at 5:43 PM, Joe Witt <joe.w...@gmail.com> wrote: br/>> Team, < br/>> Alrighty Apache NiFFi 1.20.0 is official! br/>> As a result our Apache NiFFi git branch 'main' is now officially set up as our go forward line and is 2.0.0-SNAPSHOT as of now. br/>> To continue releases as needed for the 1.x linee such as 1.21.0-SNAPSHOT as would come next we now have 'support/nifi-1.x'. It is already setup for 1.21.0-SNAPSHOT versioning. We will need at least one such release on that line for migration tooling to help users move from that 1.x line to the 2.x line but depending on how long 2.0 takes to settle we may have more. Whatever it takes. br/>> Exciting times!! br/>> Thanks < Joe br/>> On Tue, FFeb 7, 2023 at 8:40 AM Joe Witt <joe.w...@gmail.com<mailto:joe.w...@gmail.com>> wrote: br/>>> Team < br/>>> As you commit to the main line now pleease start using whatever the latest relevant feature release is on the 2.x line which right now would be 2.0.0. If we find we need to do a 1.21 and so on we'll pull those commits down as we would for any other mx release in the past but the 'main' line becomes 2.0.0 now. br/>>> Thanks < Joe br/>>> On Mon, FFeb 6, 2023 at 10:44 AM Joe Witt <joe.w...@gmail.com<mailto:joe.w...@gmail.com>> wrote: br/>>>> Team, < br/>>>> I think we are there!! Going to kick out RC1 now. br/>>>> Thanks < br/>>>> On Mon, Jan 30, 2023 at 11:29 AM Joe Witt <joe.w...@gmail.com<mailto:joe.w...@gmail.com>> wrote: br/>>>>> Team, < br/>>>>> As you can see I've noot kicked off the RC yet. Many bug fixes/dependency updates are happening. Ideally we'll wait until nar Maven plugin goes and we're trying to fix some nifi registry/nifi interaction issues as well. Still will get the RC out as soon as we can. br/>>>>> Thanks < br/>>>>> On Mon, Jan 23, 2023 aat 11:12 AM Joe Witt <joe.w...@gmail.com<mailto:joe.w...@gmail.com>> wrote: br/>>>>>> Hello < br/>>>>>> Here is a goodd picture of what the 1.20 RC looks like. I've tagged several JIRAs today to ensure we get them in. A theme is really around stabilizing nifi/nifi-registry integration as we're seeing substantial uptick in usage and thus various community reported findings. We'll get that quite smooth with these included. br/>>>>>> https://issues<https://issues/>.. apache.org/jira/projects/NIFI/versions/12352581<http://apache.org/jira/projects/NIFI/versions/12352581> br/>>>>>> Thanks < br/>>>>>> On Mon, Jan 233, 2023 at 8:50 AM Joe Witt < joe.w...@gmail.com<mailto:joe.w...@gmail.com>> wrote: br/>>>>>>> Team, < br/>>>>>>> I'm goiing through the outstanding JIRAs/PRs and flagging which look like they should be 'must have' for 1.20 and then will work the RC as soon as those land. br/>>>>>>> Hopefullly have the RC up within a day or two but we'll see how these land as some have review comments pending action. br/>>>>>>> Thanks br/>>>>>>> On Thu,, Jan 12, 2023 at 2:53 AM Isha Lamboo < isha.lam...@virtualsciences.nl<mailto:isha.lam...@virtualsciences.nl>> wrote: br/>>>>>>>>; Hi all, br/>>>>>>>>; I would like to contribute to the migration tooling (mostly testing I suppose) when that comes up. br/>>>>>>>>; My team's largest client has a completely template-based pipeline with external scripts replacing variable values before deploying to target clusters, so we've already started looking at this when the goals for 2.0 were discussed and approved. The migration to flowdefinitions and parameters is quite complex and we've hit several blockers when we tried to implement a direct translation. br/>>>>>>>>; I expect that any time I spend helping to improve the tooling will pay off handsomely for our clients. br/>>>>>>>>; Regards, br/>>>>>>>>; Isha br/>>>>>>>>; -----Oorspronkelijk bericht----- Van: Adam Taft <a...@adamtaft.com<mailto:a...@adamtaft.com>> Verzonden: woensdag 11 januari 2023 23:42 Aan: dev@nifi.apache.org<mailto:dev@nifi.apache.org> Onderwerp: Re: [discuss] NiFi 1.20 and NiFi 2.0 br/>>>>>>>>; This is really insightful and spot on ... br/>>>>>>>>; Kevin wrote: Good migration tooling will take a while to develop and test, and the core contributors to that effort may not have sufficient variety of flows to evaluate when the migration tools are "done" for the majority of the community to have success upgrading to 2.x. A milestone release would allow us get more feedback on migration over a longer period than the vote window of an RC candidate. br/>>>>>>>>; It's exactly this case, that an early 2.0 release might not have had time to fully work its way through existing production deployments, that's concerning. The pace and voting of an "RC" is much too short to get any quality feedback from users in the field. br/>>>>>>>>; I think it's really smart to consider the "Milestone" release approach here. We release 2.0.0-M1, 2.0.0-M2, ... waiting an adequate amount of time for feedback. We can put these milestones on a calendar, as needed, so that feedback is required some 'x' number of weeks/months after each milestone. br/>>>>>>>>; And to this end, I'd personally rather see us keep the 'main' branch current with the 1.x line _until_ we're ready and are satisfied with the end goals of the 2.0 release objectives. When the milestone releases have been completed and there's a comfort level with the 2.x line, it's at the point we'd isolate the 1.x line into its own branch and switch main over to the 2.x line. br/>>>>>>>>; This is an attractive way of: a) continuing business-as-usual with the 1.x line b) making headway on the 2.x release milestones c) giving adequate time for feedback against the 2.0 milestones coming from the field br/>>>>>>>>; I don't mind the known-unknowns. But it's really the unknown-unknowns that are going to drive a delay in the 2.0 release. I think it's smart to be able to get some of the unknowns ironed out before we finalize the 2.0 release ceremony. The milestone approach really helps with that. br/>>>>>>>>; /Adam br/>>>>>>>>; On Wed, Jan 11, 2023 at 11:11 AM Kevin Doran < kdo...@apache.org<mailto:kdo...@apache.org>> wrote: br/>>>>>>>>;> Sorry, Joe, I was not clear, and to be honest the two thoughts are somewhat unrelated in my mind too :) br/>>>>>>>;>> I agree that good migration tooling is key. Otherwise, we risk users staying on 1.x or creating a schism of 1.x and 2.x users. br/>>>>>>>;>> Good migration tooling will take a while to develop and test, and the core contributors to that effort may not have sufficient variety of flows to evaluate when the migration tools are "done" for the majority of the community to have success upgrading to 2.x. A milestone release would allow us get more feedback on migration over a longer period than the vote window of an RC candidate. br/>>>>>>>;>> Perhaps we could continue to release from the 1.x line (including minor releases with some features) until we are ready to drop the "milestone" qualifier from 2.0.0, and only then put 1.x into maintenance-only status. It would be the same proposal to move main to target 2.0.0-M1, but relax restrictions for what can land on the 1.x branch and be open to a 1.21, 1.22, etc. if 2.0.0 work takes longer than anticipated. For example, maybe we would be open to landing new/backported processors on the 1.x branch, but not core framework features or API changes. br/>>>>>>>;>> This might not be necessary, but I think it is fair that saying "no new features on 1.x" and also "no new features in 2.0.0" puts the project in a rough place if 2.0.0 takes longer than a few months, so if we go that route, we need to commit to a quick release of 2.0.0 that most users can move to easily. br/>>>>>>>;>> Thanks, Kevin br/>>>>>>>;>> On Jan 11, 2023 at 12:32:46, Joe Witt < joe.w...@gmail.com<mailto:joe.w...@gmail.com>> wrote: br/>>>>>>>;>>> Kevin, br/>>>>>>;>>>> Yeah we can do whatever we want as far as 'releases' of 2.0 that are prior to us officially considering it 2.0/stable. br/>>>>>>;>>>> That said - the migration tooling will be key to provide as we need to make the bridge as solid and stable as possible to help someone move from 1.x to 2.x. I dont know how related these two concepts (milestone releases and 1.x to 2.x ease really are). br/>>>>>>;>>>> Thanks br/>>>>>>;>>>> On Wed, Jan 11, 2023 at 10:27 AM Kevin Doran < kdo...@apache.org<mailto:kdo...@apache.org>> wrote: br/>>>>>>;>>>> [hit the wrong keyboard shortcut, here is the rest of my thoughts] br/>>>>>>;>>>> br/>>>>>>>>>> On this pooint from David: br/>>>>>>;>>>> br/>>>>>>>>>> We may neeed to have a longer release candidate period, or more incremental br/>>>>>>;>>>>> fix releases br/>>>>>>;>>>>> for the initial 2.0.0 release train, but I do not expect delaying a 2.0.0 br/>>>>>>;>>>>> release for new features, as that is not part of the release goals. br/>>>>>>;>>>>> br/>>>>>>>>>> br/>>>>>>>>>> br/>>>>>>>>>> Would the community benefit from one or more milestone releases of 2.0, to br/>>>>>>;>>>> allow for a wider group to run / live on the proposed 2.0 prior to br/>>>>>>;>>>> releasing it as "stable"? I know we've never done a milestone release in br/>>>>>>;>>>> the past, and I'm not sure what ASF guidance is on the topic, but if it br/>>>>>>;>>>> could be beneficial we could look into that. br/>>>>>>;>>>> br/>>>>>>>>>> Cheers, < br/>>>>>>t;>>>> Kevin br/>>>>>>;>>>> br/>>>>>>>>>> On Jan 11,, 2023 at 12:22:43, Kevin Doran <kdo...@apache.org<mailto:kdo...@apache.org>> wrote: br/>>>>>>;>>>> br/>>>>>>>>>>> I thinnk this is a good, practical discussion. br/>>>>>>;>>>>> br/>>>>>>>>>> br/>>>>>>>>>>> On the one hand, we can''t put off 2.x any longer as we really need to br/>>>>>>;>>>>> updated the minimum required Java to 11. Updating main development to br/>>>>>>;>>>>> target 2.x feels like a good way drive progress on that along with the br/>>>>>>;>>>>> other 2.0 goals. br/>>>>>>;>>>>> br/>>>>>>>>>> br/>>>>>>>>>>> On the other hand, the cconcerns are valid: moving all development to br/>>>>>>;>>>>> target 2.x puts the project at risk if we cannot release 2.0.0 on a br/>>>>>>;>>>>> reasonable timeline. The restricted scope of 2.0 helps, but this stated br/>>>>>>;>>>>> release goal feels risky to me: br/>>>>>>;>>>>> br/>>>>>>>>>> br/>>>>>>>>>>> Implement Migration Toolls for Upgrading Flows br/>>>>>>;>>>>> br/>>>>>>>>>> br/>>>>>>>>>>> br/>>>>>>>>>> br/>>>>>>>>>>> - Implement automated migration where possible to remap properties and br/>>>>>>;>>>>> features br/>>>>>>;>>>>> - Implement migration tools for manual conversion of XML Templates br/>>>>>>;>>>>> to JSON Flow Definitions br/>>>>>>;>>>>> - Create documentation for manual steps necessary where br/>>>>>>;>>>>> programmatic migration cannot be implemented br/>>>>>>;>>>>> - NiFi 2.0 should be capable of starting with ghosted components br/>>>>>>;>>>>> for removed Processors or Controller Services br/>>>>>>;>>>>> br/>>>>>>>>>> br/>>>>>>>>>>> br/>>>>>>>>>> br/>>>>>>>>>>> Removing deprecated compponents should be fairly straightforward and br/>>>>>>;>>>> quick, br/>>>>>>;>>>>> but automating and documenting migration is a large effort. br/>>>>>>;>>>>> br/>>>>>>>>>> br/>>>>>>>>>>> On this po < br/>>>>>>t;>>>>> br/>>>>>>>>>> br/>>>>>>>>>>> br/>>>>>>>>>> br/>>>>>>>>>>> On Jan 10, 2023 at 09:322:31, Bryan Bende <bbe...@gmail.com<mailto:bbe...@gmail.com>> wrote: br/>>>>>>;>>>>> br/>>>>>>>>>> br/>>>>>>>>>>>> The plan as I undersstand it is not to diverge and create separate br/>>>>>>;>>>> feature br/>>>>>>;>>>>>> development on the 1.x line, so I would expect all PRs to continue to be br/>>>>>>;>>>>>> submitted only to main. We would release 1.x as needed with major bug br/>>>>>>;>>>>>> fixes br/>>>>>>;>>>>>> or critical security updates, and these would be cherry-picked and/or br/>>>>>>;>>>>>> backported as necessary, mostly without the need for PRs, the same as we br/>>>>>>;>>>>>> would do if we were bringing fixes from main (1.20.0-SNAPSHOT) back to a br/>>>>>>;>>>>>> maintenance line like (1.19.x). For precedent, we followed this same br/>>>>>>;>>>>>> approach going from the 0.x line to 1.0.0 and there wasn't any major br/>>>>>>;>>>>>> issue. br/>>>>>>;>>>>>> br/>>>>>>>>>> br/>>>>>>>>>>>> On Tue, Jan 10, 20233 at 7:07 AM Otto Fowler <ottobackwa...@gmail.com<mailto:ottobackwa...@gmail.com>> br/>>>>>>;>>>>>> wrote: br/>>>>>>;>>>>>> br/>>>>>>>>>> br/>>>>>>>>>>>> It was also mentioneed in another thread that we need to have agreement br/>>>>>>;>>>> on br/>>>>>>;>>>>>> br/>>>>>>>>>> br/>>>>>>>>>>>> our explicit strateggy and support for 1.x going forward, did that br/>>>>>>;>>>> happen? br/>>>>>>;>>>>>> br/>>>>>>>>>> br/>>>>>>>>>>>> br/>>>>>>>>>> br/>>>>>>>>>>>> FFrom: Otto Fowler <ottobackwa...@gmail.com<mailto:ottobackwa...@gmail.com>> <ottobackwa...@gmail.com<mailto:ottobackwa...@gmail.com>> br/>>>>>>;>>>>>> br/>>>>>>>>>> br/>>>>>>>>>>>> Reply: Otto FFowler <ottobackwa...@gmail.com<mailto:ottobackwa...@gmail.com>> <ottobackwa...@gmail.com<mailto:ottobackwa...@gmail.com> br/>>>>>>;>>>> br/>>>>>>>>>>>> br/>>>>>>>>>> br/>>>>>>>>>>>> Date: January 10, 20023 at 07:02:34 br/>>>>>>;>>>>>> br/>>>>>>>>>> br/>>>>>>>>>>>> To: dev@@ nifi.apache.org<http://nifi.apache.org/> <dev@nifi.apache.org<mailto:dev@nifi.apache.org>> <dev@nifi.apache.org<mailto:dev@nifi.apache.org>> br/>>>>>>;>>>>>> br/>>>>>>>>>> br/>>>>>>>>>>>> Subject: Re: [[discuss] NiFi 1.20 and NiFi 2.0 br/>>>>>>;>>>>>> br/>>>>>>>>>> br/>>>>>>>>>>>> br/>>>>>>>>>> br/>>>>>>>>>>>> There needs to be ann update to the contributing guide as to how to br/>>>>>>;>>>> submit br/>>>>>>;>>>>>> br/>>>>>>>>>> br/>>>>>>>>>>>> PRs to 1.x or 2.x ettc. br/>>>>>>;>>>>>> br/>>>>>>>>>> br/>>>>>>>>>>>> br/>>>>>>>>>> br/>>>>>>>>>>>> FFrom: Joe Witt <joew...@apache.org<mailto:joew...@apache.org>> <joew...@apache.org<mailto:joew...@apache.org>> br/>>>>>>;>>>>>> br/>>>>>>>>>> br/>>>>>>>>>>>> Reply: dev@@ nifi.apache.org<http://nifi.apache.org/> <dev@nifi.apache.org<mailto:dev@nifi.apache.org>> <dev@nifi.apache.org<mailto:dev@nifi.apache.org> br/>>>>>>;>>>> br/>>>>>>>>>>>> br/>>>>>>>>>> br/>>>>>>>>>>>> Date: January 9, 20223 at 15:53:16 br/>>>>>>;>>>>>> br/>>>>>>>>>> br/>>>>>>>>>>>> To: dev@@ nifi.apache.org<http://nifi.apache.org/> <dev@nifi.apache.org<mailto:dev@nifi.apache.org>> <dev@nifi.apache.org<mailto:dev@nifi.apache.org>> br/>>>>>>;>>>>>> br/>>>>>>>>>> br/>>>>>>>>>>>> Subject: [[discuss] NiFi 1.20 and NiFi 2.0 br/>>>>>>;>>>>>> br/>>>>>>>>>> br/>>>>>>>>>>>> br/>>>>>>>>>> br/>>>>>>>>>>>> Team, < br/>>>>>>t;>>>>>> br/>>>>>>>>>> br/>>>>>>>>>>>> br/>>>>>>>>>> br/>>>>>>>>>>>> As David mentioned iin [1] following a successful NiFi 2.0 release goal br/>>>>>>;>>>>>> br/>>>>>>>>>> br/>>>>>>>>>>>> planning - we are noow going to start moving the 'main' line to be the br/>>>>>>;>>>> NiFi br/>>>>>>;>>>>>> br/>>>>>>>>>> br/>>>>>>>>>>>> 2.0 line which will allow for the key work to take place. We will also br/>>>>>>;>>>>>> br/>>>>>>>>>> br/>>>>>>>>>>>> move niFFi 1.x to its appropriate support line. br/>>>>>>;>>>>>> br/>>>>>>>>>> br/>>>>>>>>>>>> br/>>>>>>>>>> br/>>>>>>>>>>>> It is also the case that we have nearly 100 JIRAs on NiFi 1.20 and we br/>>>>>>;>>>> have br/>>>>>>;>>>>>> br/>>>>>>>>>> br/>>>>>>>>>>>> work in there includding security items so it is time to make a release. br/>>>>>>;>>>>>> br/>>>>>>>>>> br/>>>>>>>>>>>> The intent then is tto initiate 1.20 and immediate after that change br/>>>>>>;>>>> 'main' br/>>>>>>;>>>>>> br/>>>>>>>>>> br/>>>>>>>>>>>> to 2.0. < br/>>>>>>t;>>>>>> br/>>>>>>>>>> br/>>>>>>>>>>>> br/>>>>>>>>>> br/>>>>>>>>>>>> Going forward then aall work on the 1.x line should be focused on br/>>>>>>;>>>>>> br/>>>>>>>>>> br/>>>>>>>>>>>> maintaining existingg features, dependencies, and helping 1.x users br/>>>>>>;>>>> migrate br/>>>>>>;>>>>>> br/>>>>>>>>>> br/>>>>>>>>>>>> to the 2.x line. Othherwise, new feature work will happen on 'main' as it br/>>>>>>;>>>>>> br/>>>>>>>>>> br/>>>>>>>>>>>> normally does and wiill come out in the NiFi 2.x release line. br/>>>>>>;>>>>>> br/>>>>>>>>>> br/>>>>>>>>>>>> br/>>>>>>>>>> br/>>>>>>>>>>>> Please flag key outsstanding items as we narrow down the release br/>>>>>>;>>>> candidate br/>>>>>>;>>>>>> br/>>>>>>>>>> br/>>>>>>>>>>>> for NiFFi 1.20. br/>>>>>>;>>>>>> br/>>>>>>>>>> br/>>>>>>>>>>>> br/>>>>>>>>>> br/>>>>>>>>>>>> Thanks < br/>>>>>>t;>>>>>> br/>>>>>>>>>> br/>>>>>>>>>>>> Joe < br/>>>>>>t;>>>>>> br/>>>>>>>>>> br/>>>>>>>>>>>> br/>>>>>>>>>> br/>>>>>>>>>>>> [[1] https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2 Flists.apache.org%2Fthread%2Fqo4vvdw46235y7vy2crcd6l4m11wl7jz&dat a=05%7C01%7Cisha.lamboo%40virtualsciences.nl%7Ccbea974a2c1f479d48 9d08daf42521f1%7C21429da9e4ad45f99a6fcd126a64274b%7C0%7C0%7C63809 0737572228694%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjo iV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=zSqOK9zZPqXxLuxwo0QcqKGEAc7aXjfnnm4i%2BQt2B98%3D&reserved=0 br/>>>>>>;>>>>>> br/>>>>>>>>>> br/>>>>>>>>>>>> br/>>>>>>>>>> br/>>>>>>>>>>>> br/>>>>>>>>>> br/>>>>>>>>>> br/>>>>>>>>>> br/>>>>>>>>> br/> <
