Hi Raul,
Yeah, I think 4.9.0 is a bit of a strange version number as well. But you're also right that some users will take a bit longer to move over to Karaf 3. What's more: the version may not even be as temporary for us as we would hope, perhaps we end up doing another release in that series if people in the community are asking about another Karaf 2.x based release after this one. We do want that to be based on the current ServiceMix 5 codebase (without JBI/NMR) and not on the current ServiceMix 4.x codebase? Because the latter was the original plan and we failed to get any contributors to help out with that effort. I do wonder if we won't end up confusing people as well, when ServiceMix 4.6.0 suddenly no longer has any JBI/NMR support in there. We can probably communicate that though, so it might not be that big a problem, but we might also want to reconsider Krzysztof's proposal to go with 5.x for the Karaf 2.x-based assemblies without JBI/NMR (and we can have a few of those, using Karaf 2.3.x and 2.4.x) and use 6.x for the Karaf 3-based assemblies. Wdyt? Gert Vanthienen On Mon, Feb 17, 2014 at 1:39 AM, Raul Kripalani <[email protected]> wrote: >> >> As a version 5 suggests a big major change I'd go for karaf 3 also. > > > +1. This was my reasoning too. > > And use the current base for a 4.9 as already suggested. > > > What I'm not 100% confident is about the version gap by jumping from 4.5.3 > straight to 4.9.0. This might confuse users as they'll expect to find an > ordered sequence of versions in Maven Central which will not exist. > > What's wrong with releasing a SMX based on Karaf 2.3.3 under version 4.6.0? > > To be honest, we - SMX developers - may think of 4.9.0 as a transitional > version because we're quite comfortable with upgrading to Karaf 3.0.x when > the time comes. We would hence happily adopt SMIX 5 when released. > > However, switching to SMIX5 with Karaf 3.0.x + associated OSGi + Blueprint > + Spring upgrades won't be feasible for everybody, as enterprise folks may > have custom code to migrate first. > > Therefore, version 4.9.0 may end up NOT being temporary for them. They may > be stuck on 4.9.0 forever, "stigmatized" with the label "transitional", if > they don't get the support or funding to migrate. > > At this point, I prefer to be predictable and kind to all users, and go for: > > * SMX based on Karaf 2.3.x => version 4.6.0. > * SMX based on Karaf 3.0.x => version 5.0.0. > > Regards, > > *Raúl Kripalani* > Enterprise Architect, Open Source Integration specialist > http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani > http://blog.raulkr.net | twitter: @raulvk > > On Sun, Feb 16, 2014 at 7:10 AM, Achim Nierbeck > <[email protected]>wrote: > >> Hi, >> >> As a version 5 suggests a big major change I'd go for karaf 3 also. And use >> the current base for a 4.9 as already suggested. >> >> Regards, Achim >> >> sent from mobile device >> Am 16.02.2014 08:03 schrieb "Filippo Balicchia" <[email protected]>: >> >> > For Serviecemix 5 a prefer to use karaf 3.0.* too. >> > For me is +1 >> > >> > Regards >> > >> > --Filippo >> > >> > >> > >> > >> > >> > 2014-02-15 23:17 GMT+01:00 Gert Vanthienen <[email protected]>: >> > >> > > L.S., >> > > >> > > >> > > In the "Plan for ServiceMix 5" thread, we've seen a few proposals on >> > > how to deal with the upgrade to Karaf 3. I think this discussion >> > > definitely merits a thread of its own. >> > > >> > > Personally, I would prefer to do a ServiceMix 5 release with Karaf 3 >> > > if possible, but I'm not sure how stable/unstable this actually is at >> > > the moment. The 3.0.0 release definitely had a few issues, but a lot >> > > of them have already been addressed and I think I even saw a 3.0.1 on >> > > the roadmap for the next few weeks. >> > > >> > > If this delay is all it takes to get that upgrade in ServiceMix 5, I >> > > think we should do that. However, we do not really know big the >> > > problem is. Perhaps someone could give it a go and try to figure out >> > > how big of an issue this upgrade is? The effort should definitely not >> > > be in vain, we can always commit it to another branch and start >> > > working on a later release there if necessary. Any volunteers? >> > > >> > > If we see it will just take a few more weeks to get everything in >> > > order for a Karaf 3-based release, we can always do a release >> > > candidate or two to show the world we're actually moving again and to >> > > get some feedback from the community on where we're headed - that time >> > > can actually come in quite handy to work on docs, for example. >> > > However, if the research shows that things will take too long, we >> > > probably have to come up with a 2.3.x-based release first anyway. >> > > >> > > >> > > Wdyt? >> > > >> > > Gert Vanthienen >> > > >> > >>
