On Fri, Nov 25, 2022 at 3:05 PM Nicolas Filotto <nfilo...@talend.com> wrote:
> Hi Claus, > > That sounds like a good plan, here are the first questions that I have in > mind: > > * Why do we need to keep on releasing new LTS versions of Camel 3? > * Why not simply consider 3.20 as the last LTS version of Camel 3 and > only maintain it? > This will streetc the 3.20 too much and users will ask for any kind of stuff to creep into this release and risk things to break for other users. And Camel v4 and v3 are much more similar than what we have for v2 and v3, so backporting should be easier. > * What kind of features/improvements do you want to add to Camel 3 > after releasing 3.20? > No plan, but community may ask for a new component, or some improvements to camel-kafka, or to have a new release when there is a new release of X that requires a Camel minor release etc. The v3 LTS releases will be smaller than usual, but we have the opportunity to do these releases for a period of time so there is some overlap. > * If camel-karaf is released independently, when will it be released? > My fear is that it will be desynchronized with Camel very quickly. > There has to be an active community of users and maintainers that wants to keep it up to date all the time and do releases. OSGi is dying/dead. All the 3rd party JARs are stopping to release the OSGi manifest, and we rely on a dead ASF project (ServiceMix) to do OSGi bundle releases of 3rd party JARs. Which is really saying a lot. Users should plan to migrate to other runtimes. > * > > Yeah the camel 3 release may not go on for as long in the proposed timeline, it all depends on what we can do and need. However I really think we need Camel 3 LTS for 2023 for users on Java 11, and for users that have recently migrated to Camel 3 from 2. They may not be ready to jump quickly on Camel 4 and Java 17. Also because SB3 and Q3 and JEE10 are all so new that this will still take time to stabilize and we in Camel have other components that SB or Q may not have and this may take time for these other components to support JEE10/Java17 etc. > With 2 LTS of Camel 3 and 2 LTS of Camel 4 per year, it would mean 4 LTS > versions to support at the same time, don't you think that it is too many? > > Yeah we did however support 3-4 LTS per year in Camel 2. The promise is that we want to have a 6 months cycle between LTS releases so users can migrate accordingly. This is good practice that Spring Boot and other projects follow. We will only do 1 year LTS as that is also practice what others are doing. > I'm wondering if it is not a good opportunity to rethink our LTS version > policy. Could you please remind me why we decided to have this policy (2 > LTS versions per year supported for one year)? > > I would personally prefer to have: > > * only one LTS version per year (or 2 if we keep on releasing LTS > versions of Camel 3) but supported for at least 2 years instead of one > otherwise Camel users are less inclined to migrate to the latest LTS > version because 1 year of support doesn't really worth the migration > effort, especially for big projects where the migration takes several > months. > * only propose milestone versions or equivalent between 2 LTS versions > for early adopters to add more clarity on which versions are LTS. Indeed, > for example, the next LTS version will be 3.20 while we could expect 3.22 > to be the next one after 3.14 and 3.18. With this logic, instead of > releasing 3.19 and 3.20, we could have released 3.19 M1 and 3.19, it would > then be obvious to the Camel users that only 3.19 is an LTS version as all > final versions would then be LTS versions. > > No, we should keep the current model with non LTS versions, that is also how Java does it. It has worked really well for Camel v3. We only use Milestone releases for big new versions like v2, v3 and v4, ... > What do you think of it? > > Thanks for the feedback > Regards, > Nicolas > ________________________________ > From: Claus Ibsen <claus.ib...@gmail.com> > Sent: Friday, November 25, 2022 11:42 > To: dev <dev@camel.apache.org> > Subject: Camel 4 roadmap and affect on Camel 3 > > Hi > > This is a proposal for a plan for Apache Camel 4 and how this can affect > Camel 3. > > Summary > > ======= > > The overall scope is that the leap from Camel 3 to 4 is a lot less than > going from Camel 2 to 3. > > And that we have a timebox approach where we aim for a 6 month period of > work. > > The need for Camel v4 is mainly driven by Java open source projects > migrating to jakarta APIs, > > and to keep up with popular runtimes a la Spring Boot and Quarkus, and to > jump to the next major Java version. > > Goals > > ===== > > a) Primary Goals > > 1) Migrate from javax -> jakarta (JEE 10) > > 2) Java 17 as base line > > 3) Spring Framework 6 > > 4) Spring Boot 3 > > 5) Quarkus 3 > > b) Release Goals > > 6) Release only what is ready (JEE10 / Java17 etc) > > This means that Camel components that are not ready (yet) will be > dropped in a release until they are ready. > > 7) Release core + spring boot together > > 8) Release camel-karaf independently (like we do for other Camel projects) > > c) Major Goals > > 9) Support Java 17 features such as records, multiline strings, and what > else > > 10) EIP model without JAXB dependency > > 11) Endpoint URI parsing (do not use java.net.URI) > > 12) Deprecate message.getIn() > > use getMessage() instead > > 13) Deprecate camel-cdi > > 14) Deprecate/Remove MDC logging (complex and buggy and does not fit modern > app development) > > d) Minor Goals > > 15) Remove MEP InOptionalOut (not in use) > > 16) Remove JUnit 4 support > > > Timeline > > ======= > > The timelines are ESTIMATES and the number of releases can vary depending > on need and how far we are in the process > > Feb 2023: Camel 4.0 milestone 1 > > Mar 2023: Camel 4.0 milestone 2 > > Apr 2023: Camel 4.0 RC1 > > May 2023: Camel 4.0 > > Aug 2023: Camel 4.1 LTS > > Oct 2023: Camel 4.2 > > Dec 2023: Camel 4.3 LTS > > The plan is to start working on Camel 4 after the next Camel 3 LTS release, > e.g. 3.20 which is planned for next month (December 2022). > > For Camel 3 then we slow down in releases and provide 2 LTS releases per > year. > > For example a scheduled could look as follows: > > Dec 2022: Camel 3.20 LTS > > Jun 2023: Camel 3.21 LTS > > Dec 2023: Camel 3.22 LTS (last Camel v3 release, supported until Dec 2024) > ??? > > Jun 2024: Camel 3.23 LTS (last Camel v3 release, supported until Dec 2025) > ???? > > Each Camel 3 LTS release will likely also contain less new features and > improvements as previously, as our focus and work shifts to Camel v4 > instead. > > As a recipient of an email from Talend, your contact personal data will be > on our systems. Please see our privacy notice. < > https://www.talend.com/privacy/> > > > -- Claus Ibsen ----------------- @davsclaus Camel in Action 2: https://www.manning.com/ibsen2
