Here's what I changed in
.github/workflows/check-newsfragment-pr-number.yml:
1. Added labeled and unlabeled to PR event types (line 27) — so the
workflow re-evaluates when labels are added or removed.
2. Added if condition on the job (line 39) — if: ${{
!contains(github.event.pull_request.labels.*.name, 'skip newsfragment
check') }} skips the entire job when the PR has the skip newsfragment check
label.
To complete the setup, the label needs to be created on the GitHub repo:
gh label create "skip newsfragment check" --repo apache/airflow
--description "Skip the newsfragment PR number check" --color "ededed"
You'll need appropriate permissions on the apache/airflow repo to create
the label. When the label is applied to a PR, the workflow job will be
skipped entirely (it will show as "Skipped" in the checks).
On Fri, Mar 20, 2026 at 12:10 PM Jarek Potiuk <[email protected]> wrote:
> Funny thing: Claude—that 100% created that PR in minutes after my two
> prompts (add it, add the docs) even refused to create the label (just
> explained it to me how to do it) - because we ask it in the AGENTS.md to
> never push things upstream. Good bot, nice bot. Listens to what we ask it
> to do.
>
> On Fri, Mar 20, 2026 at 12:07 PM Jarek Potiuk <[email protected]> wrote:
>
>> And of course label created. TIL:
>>
>> > gh label create "skip newsfragment check" --repo apache/airflow
>> --description "Skip the newsfragment PR number check" --color "ededed"
>> ✓ Label "skip newsfragment check" created in apache/airflow
>>
>> J.
>>
>> On Fri, Mar 20, 2026 at 12:04 PM Jarek Potiuk <[email protected]> wrote:
>>
>>> 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]
>>>> > > >> >
>>>> > > >> >
>>>> > > >>
>>>> > > >
>>>> > >
>>>> >
>>>>
>>>
