squakez opened a new issue, #6042:
URL: https://github.com/apache/camel-k/issues/6042

   ### Requirement
   
   This is a placeholder we can use to discuss the roadmap for the project 
development during 2025.
   
   ## Status of 2024 roadmap
   
   Despite the difficulties we faced during 2024, we managed to accomplish most 
(if not all) the desired areas of development we had planned (see #5019). We 
have enhanced the build experience, giving a particular focus on the "Self 
managed" Integrations. We have reorganized the code of Kamelets, enabling the 
possibility to use versioning. We have deprecated several incomplete features 
that are not commonly used and increased the quality of code from around 30% to 
almost 50% coverage.
   
   ## Areas of development for 2025
   
   Here a list of areas where I think we should dedicate during this year:
   
   * Make plain Quarkus runtime the default runtime
   * Separate more builds and operations
   * More Camel core and more Kubernetes core
   * Drop unused features
   
   I'll try to add some context in words in order to ease the meaning of each 
point.
   
   ### Make plain Quarkus runtime the default runtime
   
   From upcoming version 2.6.0 onward, you will be able to use plain Camel 
Quarkus application. This is a great simplification in terms of project 
management on our side and also for your application which are free to choose 
any Camel Quarkus as soon as they are released. This is also a great 
simplification in order to quickly and immediately move from a prototype built 
via Camel JBang to a running application on Kubernetes.
   
   ### Separate more builds and operations
   
   We have started this part already in 2024. We need to continue pushing on 
this area in order to have a cleaner separation of concerns between the builds 
and the rest of operations for any Camel application.
   
   ### More Camel core and more Kubernetes core
   
   Camel K should be thought as a **Kubernetes manager for Camel 
applications**. For this reason we should support Camel runtimes the way they 
are (hence, deprecating and removing Camel K Runtime) and simplify the 
configuration on Kubernetes. We should work more towards an automatic discovery 
of features by the operator in order to free the user from having to provide 
such a configuration manually. In that sense, we need to work on identifying 
those traits which can be further enhanced and any new feature commonly used in 
Kubernetes in conjunction with Camel applications.
   
   We need also to continue the work of simplification changing the scope or 
even removing custom resources that may be no longer relevant (for example, the 
CamelCatalog or the IntegrationPlatform).
   
   ### Drop unused features
   
   We have plenty of features that have been introduced during these years and 
are not complete or not very commonly used. This is draining a lot of 
development time we should instead spare for the main features of the project. 
Let's identify unused features and we can drop them.
   
   ### Problem
   
   a
   
   ### Proposal
   
   _No response_
   
   ### Open questions
   
   _No response_


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscr...@camel.apache.org.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Reply via email to