I would +1 the general sentiment of Felix here. I also think if the root problem is test framework doesn't properly handle using the most recent code from peer projects then that is the thing that is broken...
I generally agree that bundle version should have some semantic meaning. Also my 2cents. - Ray On Jan 4, 2017 09:42, "Felix Meschberger" <[email protected]> wrote: > Hi > > Sorry ahead for getting somewhat PITA ... > > > Am 03.01.2017 um 20:04 schrieb Christian Schneider < > [email protected]>: > > > > 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. > > As a user I don’t care for that. As a maintainer I bite the bullet to make > life for the user easier. > > > The user can just combine the bundles with the same > > version and knows they work together. > > As a user I trust the Import-Package instructions to ensure this > cooperation. Any other „work together“ dependency not declared by > Import-Package or a generic Capability/Requirement pair, IMHO is very much > not OSGi. > > > 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. > > Sorry to be blunt, this sounds like solving for lazyness. > > > > > In OSGi the bundle version does not mean much the important version is on > > the package. > > True. My remark was more from the POV of a human encountering V1 and V2 of > a bundle and assuming there is a change. If there is none, I would be > confused. > > > 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. > > Oh, I assume the bundles are already configured like that ;-) > > If you export packages with their bundle versions, you would be doing > something wrong anyway. Not looking at the source right now, but I assume > this is not the case. > > > > > 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. > > Great. This is exactly how it works for package versions: Package versions > are for the OSGi framework to wire bundles. Semantic versioning applied. > Bundle versions are for humans. It would be great to apply semantic > versioning here as well to some extent. Though not in a technically strict > sense. Still no change, no version IMHO is a good thing. > > Regards > Felix > > > > > 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=3aa4083e0c744ae1ba52bd062c5a7e > 46&URL=http%3a%2f%2fwww.liquid-reality.de> > > > > Open Source Architect > > http://www.talend.com > > <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e > 46&URL=http%3a%2f%2fwww.talend.com> > >
