[GitHub] [camel-website] apupier commented on a change in pull request #795: chore: Camel K roadmap 2022

[GitBox <gi...@apache.org>]

apupier commented on a change in pull request #795:
URL: https://github.com/apache/camel-website/pull/795#discussion_r816746794



##########
File path: content/blog/2022/03/camel-k-roadmap-2022/index.md
##########
@@ -0,0 +1,116 @@
+---
+title: "Camel K 2022 Roadmap"
+date: 2022-03-01
+draft: false
+authors: [squakez]
+categories: ["Roadmap", "Camel K"]
+preview: "A brief overview of what we've planned for 2022"
+---
+
+<sub><sup><a href='https://pngtree.com/so/Signpost'>Signpost png from pngtree.com/</a></sup></sub>
+
+During the last weeks we've been asked questions around the direction we're willing to take on the future development of **Camel K**. I think it would be good to have some blog in order to let the community understand where our efforts are going. It will be useful for every Camel K user and Camel K developer, as a guide for the future development of the project.
+
+The below list of development areas are the ones identified at the end of 2021. The order is random, we haven't identified any clear priority yet. Some of those developments are already completed (fully or partially).
+
+* Code/build (release process)
+* Installation procedure
+* API
+* CLI
+* Event Driven Architecture
+* Builder (containers, images and registry)
+* Runtime (Integration execution)
+* Observability
+* Kamelets
+
+In each section, I've tried to detail the rationale and some ideas that can be furtherly refined. There may also be reference to Github issues that are related to the requirement under discussion.
+
+DISCLAIMER: this is a wide list of desired areas we may work on. We may not be able to complete all of them for any reason, neither considered responsible for any kind of committment. The contributors must not consider this as a mandatory list of work to do, but as a suggested list of things to take in consideration when dedicating time to the project.
+
+## Code/build (release process)
+The goal we identified is to simplify and speed up the release process.
+
+* Merge Camel K runtime into Camel Quarkus
+* Multi-architecture images ([#1238](https://github.com/apache/camel-k/issues/1238))
+* Modularised build ([#2801](https://github.com/apache/camel-k/issues/2801))
+* Nightly builds ([#393](https://github.com/apache/camel-k/issues/393))
+
+We now have a chain of relationships as `Camel K >> Camel K runtime >> Camel Quarkus >> Camel`. Camel K runtime could be seen as a bootstrap of `Camel Quarkus`: this approach simplifies the overall picture and releases dependencies. We may kick off joint initiative with **Camel Quarkus** community to bring the actual **Camel K Runtime**, under the Camel Quarkus umbrella.
+Through multi architecture images we will be able to widen our target audience by extending the presence of the **Operator** on different architectures. Nightly build will also let everybody use partial fixes before any official release cycle.
+
+## Installation procedure
+We have several installation process options in place. We may need to harmonize them to simplify the maintenance of the installation procedure.
+
+* Document the usage of Kustomize ([#2758](https://github.com/apache/camel-k/issues/2758))
+* Deprecate kamel install in favor of kubectl apply -k / kustomize
+* Move to descoped OLM model
+
+There is some preliminary work introduced in release 1.7 around [Kustomize](https://github.com/apache/camel-k/releases/tag/v1.7.0). We may leverage that in order to identify a replacement for the kamel install. We should analyze how that will happen and the user experience around any new way we’ll propose to the community.
+Another thread we should follow is related to the proposal about descoped OLM. This part should be put in a wider context around the OLM project.
+
+## API
+We can start thinking of Camel K as an enablement technology. Then, it makes sense to dedicate some effort in improving the way the technology may be consumed by others. APIs and CRDs are the main scope of this section.
+
+* Provide a full description of the APIs
+* Comprehensive CRD structural schemas for tooling
+* Traits configuration schema ([#1614](https://github.com/apache/camel-k/issues/1614))
+
+Implementation of structural schema may be the goal of 2.0 as will probably require many breaking changes. Some draft was realized and it provided discussions we may take in consideration during the feature implementation (see [#2831](https://github.com/apache/camel-k/issues/2831)

Review comment:
       ```suggestion
   Implementation of structural schema may be the goal of 2.0 as will probably require many breaking changes. Some draft was realized and it provided discussions we may take in consideration during the feature implementation (see [#2831](https://github.com/apache/camel-k/issues/2831)).
   ```




-- 
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-unsubscribe@camel.apache.org

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