add blog about reactive renaming

_posts/2024-03-21-the-big-rename.adoc

@@ -0,0 +1,59 @@
+---
+layout: post
+title: 'Evolving Quarkus extension naming for clarity'
+date: 2024-04-21
+tags: announcement
+synopsis: Recently, we've made a decision to rename several Quarkus extensions that previously included the word "reactive" in their names. This blog post aims to shed light on the reasoning behind this change and what it means for you as a user and/or extension author.
+author: maxandersen
+---
+
+Quarkus is about providing a modern, efficient, and productive development experience for developers leveraging the JVM. We're committed to making it easier for you to build cloud-native applications, whether you're using traditional blocking, reactive, or virtual thread-based programming models.
+
+Historically, Quarkus has used the term "reactive" in the names of several extensions to indicate their *additional* support for non-blocking, event-driven programming.
+
+However, we've found that this terminology has led to lots of confusion and misunderstanding among our users.
+Many users mistakenly believe that using these "reactive" extensions forces them into reactive programming, even though Quarkus, by default, recommends the traditional blocking programming model for your application and only use the reactive programming model if you have needs for it (like high concurrency requirement, or the need to orchestrate many asynchronous tasks).
+
+With the recent production release of Virtual Threads in Java 21, the distinction between traditional, reactive, and now, virtual thread-based programming has become even more critical.
+
+== Our solution: a new naming strategy
+
+To address this and guide our users more effectively, we've decided to revise the naming convention for certain extensions. This change aims to clarify the capabilities and flexibility of these Quarkus extensions, making it easier for you to choose the right extension for your project.
+
+It will take effect with the release of Quarkus 3.9.
+
+Here's a summary of the changes:
+
+- **Quarkus RESTEasy Reactive** becomes **Quarkus REST**, emphasizing its general-purpose applicability beyond just reactive programming.
+- **Quarkus SmallRye Reactive Messaging** is now **Quarkus Messaging**, indicating its broader use cases.
+- Extensions that inherently push for a reactive programming model, like **Quarkus Hibernate Reactive**, will retain the "reactive" terminology.
+- **Quarkus REST Client Reactive** is simplified to **Quarkus REST Client**, unifying the naming under a more general "REST" umbrella.
+- Several other extensions have been renamed for consistency.
+
+Quarkus REST, Quarkus Messaging and Quarkus REST Client are still leveraging the reactive engine underneath for efficiency and performances.
+At the user level, this is an implementation detail.
+
+The configuration properties of these extensions have also been renamed to refer to the new names.
+
+== Impact on users
+
+These changes are designed to clarify that you are not constrained to reactive programming when using these extensions. Whether you prefer a traditional blocking approach, reactive programming, or virtual threads, Quarkus has you covered.
+
+For most projects, this renaming should not require changes, except for those having used `quarkus-rest-client` it may require some adjustments in your dependencies. We're committed to making this transition as smooth as possible. Here are a few key points to help you adapt:
+
+- **Maven relocations:** We have introduced Maven relocations for the renamed extensions, guiding you toward the new names when you update your dependencies.
+- **Config fallback:** The old configuration properties will continue to work. It is recommended to move to the new ones though.
+- **Tooling updates:** The Quarkus CLI will default to use the new names for new projects but continue to work with old names.
+- **Quarkus update:** `quarkus update` provides recipes to help perform the update/renames if/when relevant, including configuration properties.
+- **Documentation:** Our documentation was updated to reflect the new extension names, making finding the right extension for your project easier.
+- **Migration guide:** As usual, our migration guide contains https://github.com/quarkusio/quarkus/wiki/Migration-Guide-3.9[all the gory details]. However, we highly recommend the use of `quarkus update` to migrate to the new names.
+
+For current projects, we recommend continuing to use the old names if you want to remain buildable against an older version of Quarkus — otherwise, upgrade at your own pace for new names.
+
+For new projects we will default to and recommend the new names.
+
+== What this means for you as an extension author
+
+If you've developed a Quarkus extension and want to stay compatible with Quarkus LTS releases while supporting the newer versions, we recommend keeping the old names as aliases for the new ones. This will ensure that your extension remains compatible with older Quarkus versions. Relocations solve this.
+
+For extensions targeting 3.9+, you should use the new names. Possibly make a separate branch for 3.8 and older to keep the old names.