I agree that for undoing the changes it is too late. The downside is
that people then have to migrate twice but that is just a bit of effort.
Ok so what do we do for the packages org.apache.karaf.shell.console and
below. Should we use version 3.0.0 for them or a package version of
2.3.0? The 2
For the API externalisation: +1; BUT really externalized. Which means only
in a different project. Otherwise it could get quite interesting if e.g. we
need to release something differently in the 2.x branches.
For the second point I'm completely with JB (-1)
Kind regards,
Andreas
On Thu, Nov 14
+1 and -1
+1 for have a clean API and externalized, with a cleaner versioning for
Karaf 4.
-1 to revert the move that we did in Karaf 3. We did this move 1 year
before, it gives time to test and move for the other projects. I'm not
OK to move now, at 1 week for Karaf 3.0.0. We released Karaf
+1 on getting a clean API separated out from implementation and helper
classes. Once that API is there we can nicely apply semantic
versioning on it, which should make life a lot easier for people
implementing commands.
Just FYI - the bndtools.org project has recently made a lot of
progress in pro
As you all know we had and still some compatibility problems with
bundles that implement commands externally from karaf. CXF and Camel
work now but ActiveMQ still does not work with karaf 3.
There are two kinds of problems that appear with the switch to karaf 3.
1. We moved the classes from or
