Grades of breaking changes

[Georgios Andrianakis]

A user question about some potential change to supported configuration properties got me thinking that not all breaking changes are the same, even though we currently only have one label for them and they are treated in the migration guide as the same.

For example, it doesn't make sense to me that the removal of an obscure build item that only concerns a few extension developers should carry the same weight as say the removal of a configuration property.

What I am envisioning is that we have a tier system of breaking changes, like for example: "High risk", "Medium risk" and "Low risk.

WDYT?

[Sergey Beryozkin]

Hi Georgios

Makes sense, but I'd not use a word `risk` as it reads as if it has some security association but may be `migration cost` or something more compact

Thanks 

--
You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/quarkus-dev/CALeTM-mAP4%2BQTDLQQ46izn9Uy3Wh1Hm7Hm%3DySt39DGfB_bggSQ%40mail.gmail.com.

[Georgios Andrianakis]

On Sat, Mar 28, 2026 at 2:08 PM 'Sergey Beryozkin' via Quarkus Development mailing list <quark...@googlegroups.com> wrote:

Hi Georgios

On Sat, Mar 28, 2026 at 10:52 AM 'Georgios Andrianakis' via Quarkus Development mailing list <quark...@googlegroups.com> wrote:

A user question about some potential change to supported configuration properties got me thinking that not all breaking changes are the same, even though we currently only have one label for them and they are treated in the migration guide as the same.

For example, it doesn't make sense to me that the removal of an obscure build item that only concerns a few extension developers should carry the same weight as say the removal of a configuration property.

What I am envisioning is that we have a tier system of breaking changes, like for example: "High risk", "Medium risk" and "Low risk.

WDYT?

Makes sense, but I'd not use a word `risk` as it reads as if it has some security association but may be `migration cost` or something more compact

Yeah, I like that 

Thanks 

--
You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/quarkus-dev/CALeTM-mAP4%2BQTDLQQ46izn9Uy3Wh1Hm7Hm%3DySt39DGfB_bggSQ%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/quarkus-dev/CAMsYBfUvxM9CTxACdURusmPD5YaEPMC%3DJPWB8qApwm%3DSE_GgTA%40mail.gmail.com.

[Max Rydahl Andersen]

+1 on some more nuances.

I think about in two dimensions - thats at least what I was trying to get to when trying to apply revapi in past which could be used to spot/record these.

1) Affected code: User and/or Extension (in general we've been protecting users more than extensions because if extension gets updated users are fine)

2) Impact level: how big impact (low,med,high or similar)

i.e. Extension with High Impact  that is in extensions we can ensure get updated is more tolerable than End User low impact.

/max

To view this discussion visit https://groups.google.com/d/msgid/quarkus-dev/CALeTM-mmTteb2TODW6chFjfO-fGNjpa1Ps11LP-kVOqRyTwAgg%40mail.gmail.com.

--

/max

https://about.me/maxandersen

[Georgios Andrianakis]

On Mon, Mar 30, 2026 at 3:23 PM 'Max Rydahl Andersen' via Quarkus Development mailing list <quark...@googlegroups.com> wrote:

+1 on some more nuances.

I think about in two dimensions - thats at least what I was trying to get to when trying to apply revapi in past which could be used to spot/record these.

1) Affected code: User and/or Extension (in general we've been protecting users more than extensions because if extension gets updated users are fine)

2) Impact level: how big impact (low,med,high or similar)

i.e. Extension with High Impact  that is in extensions we can ensure get updated is more tolerable than End User low impact.

Indeed! 

To view this discussion visit https://groups.google.com/d/msgid/quarkus-dev/CAHL%3D7VsYpvWgvMOsTL9nLP3zC1Aem1cB64LB_FpMZsdeqSnzQQ%40mail.gmail.com.

[Paul C-B]

As a "user" I would really really like to know about something that
could result in runtime behaviour changes that otherwise I would not
know about. For me these are CRITICAL. Stuff that comes out at compile
time and breaks builds is not such a big deal as I know I just
upgraded, now see a compile error and can review the release notes to
know why.

So in essence what I'm saying is changes that break builds are by
nature not as high a grade of change as ones that change runtime
behaviour in a way that is unexpected. The only time we hit this was
when the health check endpoint changed paths and our ALB health checks
failed everything as being down. That has many years ago and to be
honest the only change we ever has that impacted us negatively at
runtime.

On Mon, 30 Mar 2026 at 15:17, 'Georgios Andrianakis' via Quarkus

> To view this discussion visit https://groups.google.com/d/msgid/quarkus-dev/CALeTM-n9R8auDfkAfNuyZUb9ooGJRp5-7eRQoCfju%2BnVNbMP9A%40mail.gmail.com.

[Georgios Andrianakis]

Great point in making the distinction between build time and runtime breakage!

To view this discussion visit https://groups.google.com/d/msgid/quarkus-dev/CAMd%3DrQ_wOPM9i8KTfx2FH8WxymS2Wocy3XR17sgpGjy0uGWn5g%40mail.gmail.com.