No, we can't do in this way. We need to first release the camel bits, then we can also decide to go in parallel, but the first step is release the main camel baseline.
Il giorno ven 13 mar 2020 alle ore 15:04 Jean-Baptiste Onofre < j...@nanthrax.net> ha scritto: > Hi Zoran, > > I think we can do all releases in a row using kind of meta repository. > The release manager should be careful to checkout all required > repositories. > > Thoughts ? > > Regards > JB > > > Le 13 mars 2020 à 15:02, Zoran Regvart <zo...@regvart.com> a écrit : > > > > Hi Cameleers, > > I'm for splitting, I think in mid to long term this will enable us to > > run checks on pull requests and allow us to iterate faster. > > > > I think we should rethink release process, in a sense that I think we > > should try to release from several repositories at the same time. Not > > sure if there's a way to ease the effort for the release manager, but > > perhaps we should try to invest into that as well. > > > > zoran > > > > On Fri, Mar 13, 2020 at 11:06 AM Jean-Baptiste Onofre <j...@nanthrax.net> > wrote: > >> > >> Hi Andrea, > >> > >> It makes sense to "mimic" spring-boot. > >> > >> I have some WIP on Camel Karaf (not directly related to OSGi). I also > have some non-OSGi Karaf support, but it will be similar to some > starter/BOM similar to spring-boot. > >> > >> Regards > >> JB > >> > >>> Le 13 mars 2020 à 10:00, Andrea Cosentino > <ancosen1...@yahoo.com.INVALID> a écrit : > >>> > >>> Hello, > >>> > >>> We already moved the Spring Boot code and all the SB starters into a > separated git repository for convenience and to make the core independent. > And the same was done for Camel Quarkus, which started as a separated sub > project from the beginning. And we also recently moved the examples out > into its own git repository. > >>> > >>> We should do the same for Karaf/OSGi support for multiple reasons: > >>> - Having a separated repository will make easier and faster to release > new stuff and fixes without rebuilding the core part (this would be > something really useful) > >>> - We could have separated documentation as we already have for Spring > Boot > >>> - We could make the main camel repository lighter > >>> - It’s much easier to find code related to OSGi/Karaf as its all > together in > >>> - We can then add Karaf as a sub project to the Camel website (see > projects menu item) > >>> - We can have separated documentation on the website for Karaf/OSGi > >>> - We can generate a list of components that are supported in > Karaf/OSGi and also publish this on the website > >>> > >>> If we follow this path, we could be able to add new supported > platforms in the future without having to modify the core part. > >>> > >>> We envision that we only need to move core/camel-core-osgi, and all > the osgi components, and together with the karaf features and karaf > commands, and the itests. We will continue to generate OSGi MANIFEST.MF in > the JARs from the main Camel so they are still OSGi bundles. > >>> > >>> The end result would essentially be the same as today. Camel will > continue to be supported and work on Karaf. > >>> > >>> And we think we should do this before the first LTS release of Apache > Camel, which is planned to be Camel 3.3.0. So ideally we get this done for > Camel 3.2.0 so more people in the community can get their hands on a > release and provide feedback. > >>> > >>> This will require some effort but we do believe it’s worth the work. > >>> > >>> Thoughts? > >>> > >>> -- > >>> Andrea Cosentino > >>> ---------------------------------- > >>> Apache Camel PMC Chair > >>> Apache Karaf Committer > >>> Apache Servicemix PMC Member > >>> Email: ancosen1...@yahoo.com > >>> Twitter: @oscerd2 > >>> Github: oscerd > >> > > > > > > -- > > Zoran Regvart > >
