Hi All, ## 2.4.0 Release
Within the next two weeks, I am planning to release Apache Celix 2.4.0. Currently, only two issues remain for the 2.4.0 milestone [1]: one concerning documentation updates (#99) and another regarding changes.md (#632). For #99, I will likely update the subproject document and review the introduction and building documentation. For the other document items mentioned I'll create separate issues to be addressed later. If anything is missing from the 2.4.0 release, please let us know, and we can consider including it. ## 3.0.0 Preparation Following the release of Apache Celix 2.4.0, we are planning a major update (3.0.0). This also means that post-2.4.0 release, breaking changes will be introduced, including the removal of certain libraries, headers, functions, and bundles. For a more complete overview of the anticipated breaking changes, see issue #509 [2]. The primary focus of these changes will be: - Removal (or non-export) of the old C API that doesn't utilize a `celix_` prefix. - Removal of unused/unmaintained bundles. This includes the pubsub bundles. So, why are these breaking changes being introduced? Trimming the API is intended to streamline the public API of Apache Celix, making the framework more manageable, especially by a smaller team. Regarding the removal of certain libraries/bundles and, in particular, the pubsub bundles: My perspective is that the Apache Celix project should concentrate on providing a native OSGi framework. This framework should come with associated bundles that align with (and adapt as needed) the OSGi specification, while also offering advanced features, such as the Event Admin with support for remote events. While the PubSub bundles offer valuable functionality, IMO they should not be part of Apache Celix. Users can still access the PubSub bundles from previous Apache Celix versions. In closing, I believe a potential future goal for Apache Celix could be to provide a native dynamic service framework promoting polyglot solutions within a singular native process, based on a C API and implementation. This could lean towards a low-level polyglot approach, emphasizing FFI usage to create framework API bindings and facilitating C-styled services to bridge various languages without requiring a VM. Presently, Apache Celix supports C and C++, but integrating Rust and Python could be beneficial. Although Python support might depend on a VM (PVM), it could be a worthy inclusion given that many C/C++ developers are familiar with Python. I share these thoughts as "food for thought" but also to highlight that simplifying the Apache Celix framework and its bundles would make achieving these goals more feasible. 1: https://github.com/apache/celix/milestone/4 2: https://github.com/apache/celix/issues/509 What are your thoughts? Best regards, Pepijn
