I have no idea how compatible jetty 9 and pax web 4 are. I think the
question should be if our users would have to do changes in their code.
If yes then we should delay the upgrade to 4.0 if not then there is no
issue.
What I wanted to say about karaf 4 is the way we do our versioning of
packages at the moment we would cause issues to our users by doing a
major version. Even if we introduce no incompatible changes the package
update to 4.0.0 would cause problems to our users.
Christian
On 04.02.2014 09:19, Achim Nierbeck wrote:
Ok, so as far as I'm concerned, we won't do an upgrade to Pax Web 4.0 with
Jetty 9 in a Version 3 then.
regards, Achim
2014-02-04 Christian Schneider <[email protected]>:
I think we should not create a 4.0.0 version without doing incompatible
changes.
In marketing major versions are used to tell people that big functional
changes/additions have been done. The idea there is that a major version
sells better.
Our environment is very different though. Technically a major version
means incompatible changes. Especially in OSGi major versions are a big
maintenance issue for everyone using the system (assuming the package
version also reflect the major version). By default their imports will
exclude the major version.
So if the switch to SCR is only visible internally then I think we should
do it in a minor version.
So I propose we first release a 3.0.1 with as many fixes as possible. Then
we theoretically could start the DS migration. We can delay the switch of
course but I would not combine it with a 4.0 release and instead do it
whenever we see fit.
Christian
On 03.02.2014 16:00, Jean-Baptiste Onofré wrote:
-1
I would plan this for Karaf 4.0.0, even if it's internal.
It's an important jump internally in Karaf, and should be addressed in a
major release.
We just release Karaf 3.0.0, and we have to let people and other projects
to move smoothly (even if as you said, you should not have impact).
Regards
JB
On 02/03/2014 03:52 PM, Ioannis Canellos wrote:
A while back we discussed about migration from Blueprint to SCR and we
all agreed that it was a nice thing to do.
The question is how to do it, without making maintenance hard and also
without taking ages to deliver this new feature
I think that this should be done in 3 steps:1
i) Migrate from Blueprint to SCR.
ii) Define features for "Aries Blueprint"
iii) Make Blueprint Optional.
The first step could be done as part of a Karaf 3.1.0 release. Since
all changes are internal and the only thing that would be required is
to install SCR by default, it doesn't have to be a major release (in
fact it could even be a micro release). The benefit of this approach
is that we will not have to maintain an other branch that would
require extra maintenance, until we are ready for step (ii).
Once we have SCR in our Karaf 3 branch, we can define features for
aries blueprint and wait for the rest of the projects of the eco
system to pickup those features, were necessary.
When camel, cxf, activemq have picked up the changes in our features
and have performed a release or two, we can proceed to the final step
and have Blueprint not installed by default
Thoughts?
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
