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/>
