Switching Quarkus main to 4 early

[Guillaume Smet]

Hi,

We discussed this with Clément today and we think the best is to switch main to Quarkus 4 early. The main reason is that forward porting patches is hard and it's a lot more logical to backport what we think is of value in 3.x (which might not be everything), rather than having to port everything to 4.

And we have all the infra in place for backports, a proven process, and a lot of experience with it.

So the idea is to:

- create a 3.x branch for any 3.x development with the idea that 3.40 LTS released in September will be the last 3.x minor

- have everyone iterating in main on Quarkus 4, have everyone test Quarkus 4...

This is not exactly what we planned and we have a very early slot to do that before things become more chaotic on my side (especially with RivieraDev and July 14th coming - it's a public holiday here, and it's a long story involving firemen dancing with loud music: I can't be at home on July 13th and 14th).

So... the idea would be to do the switch this Saturday (yay!).

Schedule would be:

- On Thursday (tomorrow!) evening 7PM Paris time - we block any push to main

- On Friday, Clément will sync the 4.x branch one last time

- On Saturday, I will switch the branches and rebase the most pressing PRs

- All should be good for you when you go back to work on Monday - except you will all be using Quarkus 4

If you have a big issue with this plan, please contact Clément and me directly as the clock is ticking :).

Let's hope everything goes well :).

-- 

Guillaume

[George Gastaldi]

I'd like to know the QE team thoughts on it. My biggest concern is how much of a burden this will add to the QE team by having to fix the QE tests we have in https://github.com/quarkus-qe/quarkus-test-suite and https://github.com/quarkus-qe/beefy-scenarios when the main branch changes. 

Can we also add a step before this switch to test against these repositories and make sure they remain green?   

[Eric Deandrea]

Will all the quarkiverse/other nightly builds against main automatically be switched? Or should those nightly builds against main stay building against quarkus 3?

Eric Deandrea

Java Champion

Senior Principal Software Engineer

Quarkus | LangChain4j | Docling-Java

Red Hat

edea...@redhat.com    M: 603.453.5840

--
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/CALt0%2Bo9B4eCoX%3DuMnSRyPXoLqHtzuu7q4uj6YqE%2Bz8dbXpKvQg%40mail.gmail.com.

[Rostislav Svoboda]

Hi.

Both repos are integrated in Ecosystem CI, I think this is general concern for all the participants.

We can build against the 3.x branch if needed for daily runs on the GitHub side; that shouldn’t be a big issue. We have daily/weekly on the Jenkins side; that part can be adjusted.

After 3.40 LTS, I think we should switch to test against main. I don’t think it will be possible to chase both 3.x and main with our CI runs.

I have a few concerns with the switch:

 - Would be 3.27/3.33 LTS backport labels put only on PRs for 3.x branch?

 - How would 3.40 backports work in the future? That stream will be supported for quite some time.

     - Main will be expected to receive bigger and breaking changes, while the 3.40 LTS stream should be about stability, as it’s gonna be the last LTS for the 3 series.

     - Will contributors be asked to prepare changes for the main and 3.x/3.40 branches for backport topics?

Rostislav

-- 
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/561734da-40c6-4fbe-b3ac-8c847cbb68a7n%40googlegroups.com.

[Guillaume Smet]

Yeah everything targeting main will target the Quarkus 4 branch.

Now, we can certainly tweak the scripts to make them build Quarkus 3.x for now but the end game should be to have extensions tested with both so that we have an idea of what is going to break with 4.

I fully expect some chaos but I think it's better to fix it now.

To view this discussion visit https://groups.google.com/d/msgid/quarkus-dev/CAOTfCRXyO9er3gz1CLv0%2B0u7t2HO9DHqGjTT%3DGLFyk2dYhom0w%40mail.gmail.com.

[Max Rydahl Andersen]

wouldn't we need both 3.x and 4.x testing for ecosystem CI (at least for some extensions) in any case? 

[Max Rydahl Andersen]

oh and btw +1 on 3.x / main - makes issues visible while not blocking....(I'm assuming we have ways to still test 3.x for its upcoming releases too)

[Eric Deandrea]

———————
Eric Deandrea
Java Champion
Sr. Principal Software Engineer
Red Hat North America
edea...@redhat.com

Sent from a mobile device

On Thu, Jun 25, 2026 at 1:22 AM 'Max Rydahl Andersen' via Quarkus Development mailing list <quark...@googlegroups.com> wrote:

wouldn't we need both 3.x and 4.x testing for ecosystem CI (at least for some extensions) in any case? 

That was my next question. And by doing that won’t that double the amount of time/resources needed each night to run the ecosystem CI?

To view this discussion visit https://groups.google.com/d/msgid/quarkus-dev/17ad7421-fb69-4b30-aab7-524a6fe01a69n%40googlegroups.com.

[Guillaume Smet]

On Thu, Jun 25, 2026 at 3:27 PM 'Eric Deandrea' via Quarkus Development mailing list <quark...@googlegroups.com> wrote:

On Thu, Jun 25, 2026 at 1:22 AM 'Max Rydahl Andersen' via Quarkus Development mailing list <quark...@googlegroups.com> wrote:

wouldn't we need both 3.x and 4.x testing for ecosystem CI (at least for some extensions) in any case? 

That was my next question. And by doing that won’t that double the amount of time/resources needed each night to run the ecosystem CI?

Sure but that's where the amazing work done by George pays off: we used to rebuild the entire Quarkus tree for each Ecosystem run of every project,

and we now avoid that by consuming snapshots, which drastically reduced our CI resource usage for Ecosystem CI. 

[Guillaume Smet]

As announced, main is currently locked.

We will reopen it before end of day Saturday.

-- 

Guillaume