I'll add more info in the announcement on Monday once I have all the details about which typologies of issues can be caused by this particular regression.

As mentioned, the issue wasn't in Quarkus itself but in Vert.x and it's this one: github.com/eclipse-vert... . Now, it's not exactly easy to understand which problems it could have caused.

We will add more information soon but the priority was to get the release out (and timing was less than ideal). As to the problems you encountered, happy to start a conversation about what we can improve. I understand the urge to vent on social media but it won't make the project better.

#quarkus MCP server 1.1.0 is out! With progress, roots and sampling APIs... ⚡https://github.com/quarkiverse/quarkus-mcp-server/releases/tag/1.1.0

Believe it or not, the next release of Quarkus will be the 365th release since Quarkus became a thing, 6 years ago. It will be one year of release days! I released the large majority of them but this will change a bit with @janmartiska.bsky.social taking the responsibility for some LTS streams!

Thanks!

Thanks to me and a lot of others! That's the plan!

In 2016, I joined Red Hat to work on the Hibernate projects. At the end of 2018, I started working on a project that would become Quarkus. Soon, I will be joining IBM to continue my work on Quarkus. I truly believe Java has a bright future. It was already excellent and it's improving fast.

If you encounter a bug in Open Source software, don't live with it. Your future self will thank you: it will hit you at the worst moment. Assemble a reproducer, create an issue and more often than not, you'll get lucky. Here's to another example in the Quarkus project. github.com/quarkusio/qu...

I decided try to reproduce it based on the stacktrace we got. I managed to do it and posted the reproducer. One hour later, my colleague created a PR with a fix.

So please, pretty please, provide reproducers, it makes a huge difference and is the best guarantee to get your issues fixed promptly.

Also building a simple reproducer quite often give us a better idea of where to look at because you will have to isolate the issue. github.com/quarkusio/qu... is a good example of this. We didn't have a proper way to reproduce it. My colleague decided to close the issue - which is our process. 🧵

For Quarkus, we often ask for simple reproducers when users report an issue. It might seem like wasted time for you but it's not. It happens often that the information is not enough to reproduce the issue and trying to guess how we can trigger the error is a massive waste of time on our time. 🧵

Wrapping 2024 on GitHub. If there was one thing to remember for next year: focus time is important and the longer the focus period, the most productive it is.

Note that I'm all for finding a way to escape from this vicious circle and ideally the best way to do it is to contribute fixes that help make this thing more solid.

Yeah, unfortunately, it's a bit of a vicious circle. Given it's brittle, we are always afraid to break something and as we don't have experts to review changes, things can be slow. I'll try to have a look at the PR during the holiday.

Gradle is a very flexible and complex beast and that makes integration with it a lot more difficult... and unfortunately quite brittle. The fact that we don't have Gradle expertise in house doesn't help. Issues with test cases are welcome (and contributions even more so!).

FWIW, we have seen very weird behaviors/bugs with GraalVM for Java 17, we are not recommending it at all. Things are moving so fast, it's hard to provide stable information about the versions you should use...

👋