aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Holly Cummins <holly.k.cumm...@googlemail.com>
Subject Re: [Proposal] Use release per subproject for blueprint
Date Wed, 04 Jan 2017 17:52:39 GMT

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

Addressing this problem is what the 'build with most recent versions' build did - it would
ratchet the versions of all internal dependencies up to the latest level and then run the
tests. So across the two builds there were two test runs, one to make sure everything still
worked with the minimum declared level, and one with the latest level. 

However, that build has been broken for a while, I think.

> 
> I generally agree that bundle version should have some semantic meaning.
> 
> Also my 2cents.
> 
> - Ray
> 
>> On Jan 4, 2017 09:42, "Felix Meschberger" <fmeschbe@adobe.com> wrote:
>> 
>> Hi
>> 
>> Sorry ahead for getting somewhat PITA ...
>> 
>>>> Am 03.01.2017 um 20:04 schrieb Christian Schneider <
>>> chris@die-schneider.net>:
>>> 
>>> 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 <fmeschbe@adobe.com>:
>>> 
>>>> 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 <
>>>>> chris@die-schneider.net>:
>>>>> 
>>>>> 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>
>> 
>> 

Mime
View raw message