https://github.com/apache/airflow/pull/63983 -> adds skipping, updates docs and informs the author that they can skip the check by setting the label.
On Fri, Mar 20, 2026 at 11:37 AM Wei Lee <[email protected]> wrote: > > I think there are a lot of nuances between "remove" and "leave"—and that > is a good example of that. > > I feel changing is more toward the "leave" decision 🤔, but yep, we can > definitely find some middle ground. Then I'll keep this discussion open a > bit longer and see whether we can have a consensus 🙂 > > > We can always follow the procedure we use for > all checks: require the > "skip > > newsfragment check" label to be set. We can just follow what we do in 10 > > other similar cases. > > Yep, sounds good 👍 I can work on that next week. But if anyone’s > interested in adding it before me. Feel free to do so 🙂 > > Jarek Potiuk <[email protected]> 於 2026年3月20日週五 下午6:23寫道： > > > > A separate but related topic. How should we do if we did not add the > > newsfragment back to the time the change was made? If we create a > follow-up > > PR for that, then we won't pass the CI check. Or should we just use the > > number of the follow-up PR? > > > > We can always follow the procedure we use for all checks: require the > "skip > > newsfragment check" label to be set. We can just follow what we do in 10 > > other similar cases. > > > > J,. > > > > > > On Fri, Mar 20, 2026 at 11:14 AM Wei Lee <[email protected]> wrote: > > > > > A separate but related topic. How should we do if we did not add the > > > newsfragment back to the time the change was made? If we create a > > follow-up > > > PR for that, then we won't pass the CI check. Or should we just use the > > > number of the follow-up PR? > > > > > > Wei Lee <[email protected]> 於 2026年3月20日週五 下午6:06寫道： > > > > > > > It seems we don't have a strong consensus on this issue. If no one > > feels > > > > strongly about whether we should keep it or remove it, and no one can > > > > propose a compelling argument to persuade the other side, I will put > > this > > > > matter to a vote. > > > > > > > > I initiated this discussion because it no longer serves my original > > > > purpose. However, I'm okay if it still proves useful. I believe this > is > > > > more of a decision for release managers. (I guess these files are not > > > used > > > > elsewhere?) > > > > > > > > Kaxil Naik <[email protected]> 於 2026年3月18日週三 上午2:03寫道： > > > > > > > >> I'd be for removing the checkmark needed at the bottom. In recent > > > releases > > > >> I did, most of the things were touching more than one anyway and > what > > > went > > > >> on actual release notes had nothing to do with the "type" > > > >> > > > >> **Types of change** > > > >> > > > >> - [ ] DAG changes > > > >> - [ ] Config changes > > > >> - [ ] API changes > > > >> - [ ] CLI changes > > > >> - [ ] Behaviour changes > > > >> - [ ] Plugin changes > > > >> - [ ] Dependency changes > > > >> > > > >> On Tue, 17 Mar 2026 at 09:59, Jarek Potiuk <[email protected]> > wrote: > > > >> > > > >> > Yeah. The format is cool - we might consider adding or removing > some > > > >> > areas - but I think it's a good setup + automation. > > > >> > > > > >> > J. > > > >> > > > > >> > On Tue, Mar 17, 2026 at 8:24 AM Ephraim Anierobi > > > >> > <[email protected]> wrote: > > > >> > > > > > >> > > I’m on the same page as Wei about removing the format check. > > > >> > > > > > >> > > For our uses now, requiring a title and description is enough to > > > >> capture > > > >> > > significant changes. > > > >> > > > > > >> > > - Ephraim > > > >> > > > > > >> > > On Tue, 17 Mar 2026 at 08:07, Amogh Desai < > [email protected]> > > > >> wrote: > > > >> > > > > > >> > > > Yes, I still think we should continue using the format. > > > >> > > > > > > >> > > > Thanks & Regards, > > > >> > > > Amogh Desai > > > >> > > > > > > >> > > > > > > >> > > > On Tue, Mar 17, 2026 at 11:59 AM Wei Lee <[email protected] > > > > > >> wrote: > > > >> > > > > > > >> > > > > I think I didn't phrase it very clearly 🤦♂️ What I meant > is > > > that > > > >> > this > > > >> > > > is > > > >> > > > > the format check for significant news fragments: > > > >> > > > > > > > >> > > > > **Types of change** > > > >> > > > > > > > >> > > > > - [ ] DAG changes > > > >> > > > > - [ ] Config changes > > > >> > > > > - [ ] API changes > > > >> > > > > - [ ] CLI changes > > > >> > > > > - [ ] Behaviour changes > > > >> > > > > - [ ] Plugin changes > > > >> > > > > - [ ] Dependency changes > > > >> > > > > > > > >> > > > > I also think we should continue to keep significant news > > > >> fragments — > > > >> > I > > > >> > > > > just wanted to confirm that we still want to use this > format. > > > >> > > > > > > > >> > > > > Best, > > > >> > > > > Wei > > > >> > > > > > > > >> > > > > > On Mar 17, 2026, at 1:44 PM, Amogh Desai < > > > [email protected] > > > >> > > > > >> > > > wrote: > > > >> > > > > > > > > >> > > > > > I am in favour of keeping it. It helps in issuing news > > > fragments > > > >> > with > > > >> > > > > > structure. > > > >> > > > > > > > > >> > > > > > Thanks & Regards, > > > >> > > > > > Amogh Desai > > > >> > > > > > > > > >> > > > > > > > > >> > > > > > On Tue, Mar 17, 2026 at 11:11 AM Rahul Vats < > > > >> > [email protected]> > > > >> > > > > wrote: > > > >> > > > > > > > > >> > > > > >> +1 We should keep significant news fragments. > > > >> > > > > >> > > > >> > > > > >> Regards, > > > >> > > > > >> Rahul Vats > > > >> > > > > >> > > > >> > > > > >> > > > >> > > > > >> > > > >> > > > > >> On Tue, 17 Mar 2026 at 07:54, Zhe-You(Jason) Liu < > > > >> > [email protected] > > > >> > > > > > > > >> > > > > >> wrote: > > > >> > > > > >> > > > >> > > > > >>> I agree with Jarek and Ferruzzi about keeping the > > > significant > > > >> > news > > > >> > > > > >>> fragment. > > > >> > > > > >>> > > > >> > > > > >>> From my perspective, the news fragment serves a similar > > role > > > >> to > > > >> > ADRs > > > >> > > > > >>> (Architectural Decision Records), providing an explicit > > way > > > to > > > >> > record > > > >> > > > > >> major > > > >> > > > > >>> discussions and behavior changes. We have ADRs for > Breeze > > > >> [1], so > > > >> > > > > keeping > > > >> > > > > >>> those news fragments as ADR-like records for Airflow > Core > > > >> would > > > >> > be a > > > >> > > > > nice > > > >> > > > > >>> way to help the repo track its decision history. > > > >> > > > > >>> > > > >> > > > > >>> [1] > > > >> > https://github.com/apache/airflow/tree/main/dev/breeze/doc/adr > > > >> > > > > >>> > > > >> > > > > >>> Best, > > > >> > > > > >>> Jason > > > >> > > > > >>> > > > >> > > > > >>> On Tue, Mar 17, 2026 at 9:12 AM Ferruzzi, Dennis < > > > >> > > > [email protected]> > > > >> > > > > >>> wrote: > > > >> > > > > >>> > > > >> > > > > >>>> Personally I like it for major updates and features. > > > >> > > > > >>>> ________________________________ > > > >> > > > > >>>> From: Jarek Potiuk <[email protected]> > > > >> > > > > >>>> Sent: Monday, March 16, 2026 4:00 AM > > > >> > > > > >>>> To: [email protected] <[email protected]> > > > >> > > > > >>>> Subject: RE: [EXT] [DISCUSS] Do we still need the > > > significant > > > >> > > > > >>> newsfragment > > > >> > > > > >>>> check introduced in #44378? > > > >> > > > > >>>> > > > >> > > > > >>>> CAUTION: This email originated from outside of the > > > >> > organization. Do > > > >> > > > > not > > > >> > > > > >>>> click links or open attachments unless you can confirm > > the > > > >> > sender > > > >> > > > and > > > >> > > > > >>> know > > > >> > > > > >>>> the content is safe. > > > >> > > > > >>>> > > > >> > > > > >>>> > > > >> > > > > >>>> > > > >> > > > > >>>> AVERTISSEMENT: Ce courrier électronique provient d’un > > > >> expéditeur > > > >> > > > > >> externe. > > > >> > > > > >>>> Ne cliquez sur aucun lien et n’ouvrez aucune pièce > jointe > > > si > > > >> > vous ne > > > >> > > > > >>> pouvez > > > >> > > > > >>>> pas confirmer l’identité de l’expéditeur et si vous > > n’êtes > > > >> pas > > > >> > > > certain > > > >> > > > > >>> que > > > >> > > > > >>>> le contenu ne présente aucun risque. > > > >> > > > > >>>> > > > >> > > > > >>>> > > > >> > > > > >>>> > > > >> > > > > >>>> I think it's still quite useful > > > >> > > > > >>>> > > > >> > > > > >>>> On Mon, Mar 16, 2026 at 11:48 AM Wei Lee < > > > >> [email protected]> > > > >> > > > wrote: > > > >> > > > > >>>>> > > > >> > > > > >>>>> Hi all, > > > >> > > > > >>>>> > > > >> > > > > >>>>> The significant newsfragment check was introduced in > > > #44378 > > > >> [1] > > > >> > > > > >> mainly > > > >> > > > > >>>> to support the Airflow 2 to 3 migration and track > > breaking > > > >> > changes. > > > >> > > > (I > > > >> > > > > >>>> thought we only added significant newsfragments for > > > breaking > > > >> > changes > > > >> > > > > >> back > > > >> > > > > >>>> then, but Jed corrected me sometime after that.) > > > >> > > > > >>>>> > > > >> > > > > >>>>> Now that Airflow 3 is out, do we still need it? Or > maybe > > > we > > > >> can > > > >> > > > just > > > >> > > > > >>>> remove it. > > > >> > > > > >>>>> > > > >> > > > > >>>>> Best, > > > >> > > > > >>>>> Wei Lee > > > >> > > > > >>>>> > > > >> > > > > >>>>> [1] https://github.com/apache/airflow/pull/44378 > > > >> > > > > >>>>> > > > >> > > > > > > >> > --------------------------------------------------------------------- > > > >> > > > > >>>>> To unsubscribe, e-mail: > > > [email protected] > > > >> > > > > >>>>> For additional commands, e-mail: > > > >> [email protected] > > > >> > > > > >>>>> > > > >> > > > > >>>> > > > >> > > > > >>>> > > > >> > > > > > > >> > --------------------------------------------------------------------- > > > >> > > > > >>>> To unsubscribe, e-mail: > > [email protected] > > > >> > > > > >>>> For additional commands, e-mail: > > > [email protected] > > > >> > > > > >>>> > > > >> > > > > >>>> > > > >> > > > > >>> > > > >> > > > > >> > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > >> > --------------------------------------------------------------------- > > > >> > > > > To unsubscribe, e-mail: [email protected] > > > >> > > > > For additional commands, e-mail: > [email protected] > > > >> > > > > > > > >> > > > > > > > >> > > > > > > >> > > > > >> > > > --------------------------------------------------------------------- > > > >> > To unsubscribe, e-mail: [email protected] > > > >> > For additional commands, e-mail: [email protected] > > > >> > > > > >> > > > > >> > > > > > > > > > >
