Re: [DISCUSS] Migration to SCR
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 ioca...@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
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
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
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
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
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 ioca...@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/
[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
-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é jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com
Re: [DISCUSS] Migration to SCR
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 ioca...@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 dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: [DISCUSS] Migration to SCR
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
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
So, start 4.x now! :) Release early, release often. On Mon, Feb 3, 2014 at 12:09 PM, j...@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
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
