The motivation for releasing the bundles together is that it makes life easier for maintainers as well as users. The maintainer can do the complete release in one step. The user can just combine the bundles with the same version and knows they work together. It is also good for the developers as the tests always use the newest bundles. So tests always cover the newest changes. In current aries tests we often find at some point that tests still use the old versions and so are not covering errors in current code.
In OSGi the bundle version does not mean much the important version is on the package. So if we upgrade package versions using semantic versioning we should not have a problem with compatibility at runtime. By cleverly using the package versions we still can assure that more advanced users can upgrade individual bundles and keep others the same. Especially user code will be very compatible if we do not change package versions when there are no changes. We already have some examples where this works very well like Aries RSA. See https://github.com/apache/aries-rsa/blob/master/spi/src/main/java/org/apache/aries/rsa/spi/packageinfo The bundles are all released together. Still the spi package which is the most important dependency accross modules (besides the rsa spec) is still at 1.0.0. So while the bundle versions increased with every release we still can combine bundles from different releases at runtime without any problems. Christian 2017-01-03 14:04 GMT+01:00 Felix Meschberger <[email protected]>: > Hi Christian > > On a high level I disagree and would suggest to continue releasing > individual bundles. > > Plus: don’t blindly update dependency versions just because there is a new > release. > > I think the „plus“ is actually key here: With OSGi applications are bound > late at the time of deployment using the wiring „instructions“ such as > Import-Package and Export-Package. This is the essential dependency > management for bundles. > > The build time dependencies really are just that: build time. So unless > the build (the actual code, not necessairily the tests) don’t need any > newly released features, it is actually better to *not* update the > dependencies. Because this allows to update individual bundles more > independently at deployment time. > > If there are requirements, then updating makes sense. But other than > bundles implementing new API or bundles using new API, I fail to see any > need for such updates. > > There is another one: In OSGi „projects“ bundles generally evolve > independently. Releasing them in lock-step might/will create new versions > of bundles which have not actually changed. What does the new version then > purvey ? Nothing, at best it would be confusing. > > Just my $.02 > > Regards > Felix > > > > Am 03.01.2017 um 12:34 schrieb Christian Schneider < > [email protected]>: > > > > Currently the blueprint bundles are released individually. I think this > creates a lot of overhead as there are quite many bundles and for each > release you have to manually update the dependencies in several places. I > am also sure that we quite regularly forgot to update dependencies. For > example the blueprint-repository project was not updated for any recent > releases. > > > > So I propose we change the blueprint subproject to always release all > bundles and keep the bundle versions aligned. We should still be able to > make the project very stable by using package versions for the APIs. > > > > A side effect would be that we could have blueprint karaf features and > an OBR repository for other non karaf deployments in the aries blueprint > code and the maintenance would be quite low. > > > > So what do you think? > > > > Christian > > > > -- > > Christian Schneider > > http://www.liquid-reality.de > > > > Open Source Architect > > http://www.talend.com > > > > -- -- Christian Schneider http://www.liquid-reality.de <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.liquid-reality.de> Open Source Architect http://www.talend.com <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.talend.com>
