You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@karaf.apache.org by Ioannis Canellos <io...@gmail.com> on 2014/02/03 15:52:42 UTC
[DISCUSS] Migration to SCR
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:
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?
--
Ioannis Canellos
Blog: http://iocanel.blogspot.com
Twitter: iocanel
Re: [DISCUSS] Migration to SCR
Posted by Daniel Kulp <dk...@apache.org>.
I would do #2 first, even in the next patch releases. Having the feature defined doesn’t cause any problems at all and that way external projects can start relying on it, even if it is installed by default.
Dan
On Feb 3, 2014, at 9:52 AM, Ioannis Canellos <io...@gmail.com> 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:
>
> 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?
>
> --
> Ioannis Canellos
>
> Blog: http://iocanel.blogspot.com
> Twitter: iocanel
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: [DISCUSS] Migration to SCR
Posted by Achim Nierbeck <bc...@googlemail.com>.
I think, JB already published a road-map before.
Basically it boils down to one thing:
"how do you swallow a whale, piece by piece"
So, for me it's more important to have 2.3, 2.4 and 3.0.1 done.
After that let's take a look at the "new" features for 4.0 like
SCR for core, Java7 Support which is for me the biggest thing to go for
4.0, etc ...
regards, Achim
2014-02-04 Ioannis Canellos <io...@gmail.com>:
> OK then 4.x it is.
>
> And when do u feel its the right time to create a 4.x branch?
>
> --
> Ioannis Canellos
>
> Blog: http://iocanel.blogspot.com
> Twitter: iocanel
>
--
Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
Project Lead
OPS4J Pax for Vaadin <http://team.ops4j.org/wiki/display/PAXVAADIN/Home>
Commiter & Project Lead
blog <http://notizblog.nierbeck.de/>
Re: [DISCUSS] Migration to SCR
Posted by Ioannis Canellos <io...@gmail.com>.
OK then 4.x it is.
And when do u feel its the right time to create a 4.x branch?
--
Ioannis Canellos
Blog: http://iocanel.blogspot.com
Twitter: iocanel
Re: [DISCUSS] Migration to SCR
Posted by Christian Schneider <ch...@die-schneider.net>.
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 <ch...@die-schneider.net>:
>
>> 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
Re: [DISCUSS] Migration to SCR
Posted by Achim Nierbeck <bc...@googlemail.com>.
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 <ch...@die-schneider.net>:
> 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
>
>
--
Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
Project Lead
OPS4J Pax for Vaadin <http://team.ops4j.org/wiki/display/PAXVAADIN/Home>
Commiter & Project Lead
blog <http://notizblog.nierbeck.de/>
Re: [DISCUSS] Migration to SCR
Posted by Christian Schneider <ch...@die-schneider.net>.
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
Re: [DISCUSS] Migration to SCR
Posted by Achim Nierbeck <bc...@googlemail.com>.
Hi,
I really liked the idea to have a "smaller" core, though I still think it's
major change even if it is internal,
so this should go to a 4.0.
I hope we don't take another 3 years for the next major version, and I
don't plan on supporting this.
Still right now I don't see any value of opening another playground where
we have still plenty to do
with releasing a 2.3.x and 2.4.0 (where 2.3.x will hopefully be the last of
that branch) and of course
we need to harden the 3.0 branch first.
>From what I can tell right now, regarding the 3.0 hardening it is mostly a
one-man show of JB.
So please be patient to get this thing rolling. Everything to make this
transition easier like decoupling
the features, be my guest to add those :D
regards, Achim
2014-02-03 Ioannis Canellos <io...@gmail.com>:
> As I mentioned earlier, I am not really interested in the release
> version per se, but primary in the time to market and secondarily on
> what it means in terms of maintenance.
>
> As in all things, the key is balance.
>
> Release often is guaranteed way of delivering value to users,
> releasing too often may send out the wrong message (is it just me, or
> people tend to become uneasy with very often major releases?).
>
> Also releasing very often means, that as a community we will be
> supporting each major release for a small period of time, or we will
> need to increase the number of major versions we support at any given
> time. Do we have the luxury to do so?
>
> For example, let's assume that we go for a 4.x in say 3 months....
> It has proven a bit hard to maintain the long living 3.x branch along
> with 2.x (module restructures made it not trivial to just cherry-pick
> fixes from one branch to the other). If we add a third branch into the
> mix, it will become even harder.
>
> So what are we supposed to do here? Push the release back 6 - 12
> months, or until we decide we no longer need to support 2.x? In that
> case we could hold of creating a 4.x branch until we get near that
> time (to avoid the maintenance overhead). We could use this time and
> follow Dan's suggestion about letting other projects adopt the feature
> changes. But still it does sound like a long time which is meant to
> become even longer as "new features" will pile up for 4.x.
>
> Thoughts?
>
> --
> Ioannis Canellos
>
> Blog: http://iocanel.blogspot.com
> Twitter: iocanel
>
--
Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
Project Lead
OPS4J Pax for Vaadin <http://team.ops4j.org/wiki/display/PAXVAADIN/Home>
Commiter & Project Lead
blog <http://notizblog.nierbeck.de/>
Re: [DISCUSS] Migration to SCR
Posted by Ioannis Canellos <io...@gmail.com>.
As I mentioned earlier, I am not really interested in the release
version per se, but primary in the time to market and secondarily on
what it means in terms of maintenance.
As in all things, the key is balance.
Release often is guaranteed way of delivering value to users,
releasing too often may send out the wrong message (is it just me, or
people tend to become uneasy with very often major releases?).
Also releasing very often means, that as a community we will be
supporting each major release for a small period of time, or we will
need to increase the number of major versions we support at any given
time. Do we have the luxury to do so?
For example, let's assume that we go for a 4.x in say 3 months....
It has proven a bit hard to maintain the long living 3.x branch along
with 2.x (module restructures made it not trivial to just cherry-pick
fixes from one branch to the other). If we add a third branch into the
mix, it will become even harder.
So what are we supposed to do here? Push the release back 6 - 12
months, or until we decide we no longer need to support 2.x? In that
case we could hold of creating a 4.x branch until we get near that
time (to avoid the maintenance overhead). We could use this time and
follow Dan's suggestion about letting other projects adopt the feature
changes. But still it does sound like a long time which is meant to
become even longer as "new features" will pile up for 4.x.
Thoughts?
--
Ioannis Canellos
Blog: http://iocanel.blogspot.com
Twitter: iocanel
Re: [DISCUSS] Migration to SCR
Posted by James Carman <ja...@carmanconsulting.com>.
So, start 4.x now! :) Release early, release often.
On Mon, Feb 3, 2014 at 12:09 PM, <jb...@nanthrax.net> wrote:
> Good points Ioannis,
>
> my point is just about the "message" for we send to the users and community.
>
> You are right, it took long time to release Karaf 3.0.0, but it doesn't mean
> that it would be the same for 4.0.0.
>
> My point is just to send a message for users/community like: "hey, we did
> deep changes" ;)
>
> Regards
> JB
>
>
> On 2014-02-03 16:24, Ioannis Canellos wrote:
>>>
>>> I would plan this for Karaf 4.0.0, even if it's internal.
>>
>>
>> While I don't have a strong objection on having it as part of a 4.x
>> release, that would mean that it will get pushed back way into the
>> future.
>> 3.x release took us almost 3 years to get out and we stalled 2.3.x for
>> 1.5 year in favour of 3.x.
>>
>> What I take from that experience, is that its not a good idea to push
>> stuff to major releases, when they are candidates for a major release.
>>
>>> It's an important jump internally in Karaf, and should be addressed in a
>>> major release.
>>
>>
>> I agree that this is an important change. Semantic versioning doesn't
>> force us to push "important" changes to major releases. Since we are
>> talking about a change that is transparent to the user, the importance
>> of the change is a good reason to deliver it asap :-)
>>
>>> 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).
>>
>>
>> This is another good reason, for not rushing a 4.x release.
Re: [DISCUSS] Migration to SCR
Posted by jb...@nanthrax.net.
Good points Ioannis,
my point is just about the "message" for we send to the users and
community.
You are right, it took long time to release Karaf 3.0.0, but it doesn't
mean that it would be the same for 4.0.0.
My point is just to send a message for users/community like: "hey, we
did deep changes" ;)
Regards
JB
On 2014-02-03 16:24, Ioannis Canellos wrote:
>> I would plan this for Karaf 4.0.0, even if it's internal.
>
> While I don't have a strong objection on having it as part of a 4.x
> release, that would mean that it will get pushed back way into the
> future.
> 3.x release took us almost 3 years to get out and we stalled 2.3.x for
> 1.5 year in favour of 3.x.
>
> What I take from that experience, is that its not a good idea to push
> stuff to major releases, when they are candidates for a major release.
>
>> It's an important jump internally in Karaf, and should be addressed in
>> a
>> major release.
>
> I agree that this is an important change. Semantic versioning doesn't
> force us to push "important" changes to major releases. Since we are
> talking about a change that is transparent to the user, the importance
> of the change is a good reason to deliver it asap :-)
>
>> 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).
>
> This is another good reason, for not rushing a 4.x release.
Re: [DISCUSS] Migration to SCR
Posted by Ioannis Canellos <io...@gmail.com>.
> I would plan this for Karaf 4.0.0, even if it's internal.
While I don't have a strong objection on having it as part of a 4.x
release, that would mean that it will get pushed back way into the
future.
3.x release took us almost 3 years to get out and we stalled 2.3.x for
1.5 year in favour of 3.x.
What I take from that experience, is that its not a good idea to push
stuff to major releases, when they are candidates for a major release.
> It's an important jump internally in Karaf, and should be addressed in a
> major release.
I agree that this is an important change. Semantic versioning doesn't
force us to push "important" changes to major releases. Since we are
talking about a change that is transparent to the user, the importance
of the change is a good reason to deliver it asap :-)
> 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).
This is another good reason, for not rushing a 4.x release.
--
Ioannis Canellos
Blog: http://iocanel.blogspot.com
Twitter: iocanel
Re: [DISCUSS] Migration to SCR
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
-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?
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com