Hi Robert, thanks for your feedback, and I fully agree with you.
For the release, it's largely my fault for 4.2.1: I wanted to include too much fixes, upgrades and new features. My bad, and apologize for that. That's why I wanted to propose to reduce scope of the releases and do it on a regular pace, much more predictable to users/devs like you. For the changes, we are now much more "strict" in the changes we are doing. Any breaking changes is not allowed on a minor release. For the documentation, we started a huge work on this one. You can already see the user guide is largely better than before IMHO. Now the target is on the dev guide and related examples. I see your point the way you are "packaging" the features. Any reason why you don't manage your features repository by hand ? Anyway, 4.1.6 has been released and 4.2.1 will be on vote tonight. Starting for there, I will send the release agenda with a release every two months for both Karaf Container but also the subprojects. Thanks ! Regards JB On 17/08/2018 15:12, Robert Varga wrote: > Hello Jamie, everyone, > > On 16/08/18 10:46, Jamie G. wrote: >> Karaf is used / consumed heavily in the SDN world (see OpenDaylight & >> its ecosystem). >> >> For that community they do treat Karaf as a SDK for developing their >> apps, its also of course their runtime. >> >> The long support runs we provide for Karaf major versions is seen as a >> benefit as SDN deployments typically run major infrastructure. The >> release pace is a function of available time from the community - >> speaking from my experiences with Karaf releases they are a fare >> amount of work; more hands involved in testing, stabilizing builds, >> etc are always welcomed :) >> >> As to how Karaf is presented; Karaf is many things to many people, I'd >> rather keep the open development possibilities than restrict them. > > As one of the guys who spent countless hours pushing Karaf upgrades > through the OpenDaylight ecosystem and with m OpenDaylight Offset-0 TSC > Representative hat on, I would like to contribute the follow to the > discussion: > > I whole-heartily support faster and more predictable release schedule. > OpenDaylight follows strict 6 month release cadence > (https://opendaylight.readthedocs.io/en/latest/release-process/release-schedule.html). > Third-party component upgrades are integrated in the first 6 weeks, with > only very minor adjustments being done afterwards. In this context > karaf-4.2.1 and karaf-4.1.6 having slipped as much as they did is very > bad for ability to plan ahead. > > Furthermore, so far each and every Karaf upgrade has been problematic -- > partly because of the technical debt present in our code base, but more > importantly due to sheer amount of changes even a x.x.1 bump in Karaf > version brings to the table. Those changes have been quite uncontrolled > in the past -- like the change in the default TransformerFactory in > 3.0.6, which caused quite a lot of grief evidenced in > https://bugs.opendaylight.org/show_bug.cgi?id=5917. > > While we have reasons for using Karaf in OpenDaylight, it is seen by > many developers as an unneeded complication of our platform -- to the > point that there is https://lighty.io and > https://wiki.opendaylight.org/view/Events:Neon_Dev_Forum#OpenDaylight_without_Karaf_and_OSGi. > > As far as I understand the motivations, there are three drivers: > - regard of OSGi as an unnecessary complication > - the kitchen-sink nature of Karaf packaging, which brings unneeded fat, > especially considering the general move to stateless containers > - slow and painful upgrade process > > Aside from the schedule, I would like to make two technical asks: > > 1) Thoroughly document features specification > > We use features as a deployment descriptor to tie together the > components of our system, with the OpenDaylight distribution contains > around 300 individual features. While features are cool, they also seem > to be quite under-documented, especially in terms of their interplay > with the resolver -- for example, what exactly does it exactly mean to > declare a feature dependency with dependency=true and prerequisite=true > from perspective of feature/bundle lifecycle? > > 2) Split up feature repositories into individual features > > OpenDaylight is structured as a set of individual projects, which > gradually build up the platform. We use extensively karaf-maven-plugin > to generate features and the fact that individual features in > features/standard are not available as maven artifacts forces us to > define things like > https://github.com/opendaylight/odlparent/tree/master/features/odl-karaf-feat-jetty > just to get sane features generated without pulling in all of standard. > > Thanks, > Robert >
