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