Dan, Thanks for highlighting that scenario. In that case, as an improvement on the support branch, I think the title conveys the intended branch, and the pull request would also make that clear.
One other potential option is adjusting the Jira Field configuration to include a third Version field, named something like Target Version. However, with improvements and new features primarily targeting the main branch, I'm not sure that will be necessary in the long run. Regards, David Handermann On Wed, Nov 29, 2023 at 10:09 AM Dan S <dsti...@gmail.com> wrote: > > David, > What about tickets only applicable for 1.x the ticket like the one I just > created NIFI-12428 <https://issues.apache.org/jira/browse/NIFI-12428> ? > What type of label should be used for it? > > On Wed, Nov 29, 2023 at 11:04 AM David Handermann < > exceptionfact...@apache.org> wrote: > > > Team, > > > > Following the release of 2.0.0-M1, we continue to need a way to flag > > Jira issues for potential backporting to the support/nifi-1.x branch. > > > > Even small changes will likely require separate pull requests to apply > > to the support branch, due to Java language level differences. There > > are some exceptions, such as minor dependency version upgrades for > > libraries that follow semantic versioning. > > > > Rather than continuing to use the Jira Fix version field to flag the > > intended version, I propose using the Label field with the > > backport-needed flag, as shown in NIFI-12418 [1]. This is an easier > > example because it is a bug that impacts multiple versions, so the > > Affects Version field applies. > > > > When it comes to submitting pull requests, submitting against the main > > branch indicates that 2.0.0 should be targeted, and submitting against > > support/nifi-1.x indicates that version 1 should be targeted. > > > > In cases where a change should be applied to both 2.0.0 and version 1, > > the backport-needed flag signals to the reviewer that change should be > > backported by the reviewer. As mentioned earlier, given the divergence > > of main and support branches based on features and language level, > > this scenario should be less common. > > > > In cases where there are larger changes needed, separate Jira issues > > can be filed, and then linked. That will allow primary work to be > > completed on the main branch for 2.0, and separate work for the > > support branch to be tracked as needed. > > > > Some amount of evaluation is necessary on a case-by-case basis, but as > > we continue to make progress on a full 2.0.0 release, this approach > > will allow Release Managers to maintain the standard use of the Fix > > Version field as the definitive marker for issues resolved in a > > particular version. > > > > Regards, > > David Handermann > > > > [1] https://issues.apache.org/jira/browse/NIFI-12418 > >
