aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From zoe slattery <>
Subject Re: [DISCUSS] Version Policy
Date Thu, 17 Mar 2011 12:08:10 GMT
> Hold on: lets first clarify which version of a bundle/module you are
> talking of:
>    * If it is the bundle/module's own version as specfied along
>      with the bundle/module's groupId and artifactId.
>      This version is switched to the next SNAPSHOT version by the
>      maven release plugin
>      -->  I strongly suggest to keep this mechanism as is
OK - I had though that it was better to leave the version in trunk being 
the same as the release version - but as I work through making the 
changes I can see that this will not work. In a perfect world I think it 
would be right to do this, but as you suggested I don't think we can 
count on people remembering to change the bundle version to 
something-SNAPSHOT when they first make a change. I'm having trouble 
remembering it as I go along :-)
>    * If it is the dependency version of a bundle/module the situation
>      is more interesting and is probably what you are refering to.
> In the latter (dependency) case you have two situations:
> (1) you depend on new exported functionality of the dependency. In this
> case upgrade the dependency when you need the new exported
> functionality.
> (2) you don't depend on new exported functionality: refer to the lowest
> release version providing enough exported functionality the bundle
> requires. This ensures the import version is automatically set correctly
> to allow for loose coupling supported by OSGi.
> Regards
> Felix
>> There will be circumstances (maybe the majority?) when a change is made
>> in bundle a which affects no other bundle - I guess it might be hard to
>> remember to change the bundle version in this case.
>> The alternative is, as you suggest, to bump the micro version and add
>> SNAPSHOT after every release. I don't particularly mind this but it
>> gives the release manager the job of checking ALL bundles to see what
>> has changed and could be released, rather than just checking the ones
>> called blah-SNAPSHOT.
>> Zoe
>>> In addition, as I said, the maven release plugin sets the version to
>>> -SNAPSHOT (well, its a default and you can overwrite this in the
>>> release:prepare goal).
>> Yes - you can just override it. And in one sense it's completely
>> reasonable to do so. At the point of release the code in trunk is
>> exactly the same as that which is being released - therefore its version
>> is logically the same.
>>>>> Re. Bundles: I think it is solely the task of the RM to decide on the
>>>>> version to be released. But there should be some guidelines like the
>>>>> OSGi semantic versioning. On point to note (and extending OSGi's paper)
>>>>> is that in Felix and Sling we generally release even versions and have
>>>>> odd versions being SNAPSHOTs. E.g:
>>>>>      x.y.1-SNAPSHOT
>>>>>      x.y.2
>>>>>      x.y.3-SNAPSHOT
>>>>>      x.y.4
>>>>> The reason for this is that x.y.z.SNAPSHOT>   x.y.z in OSGi version
>>>>> speak, which is of course not true in real life (and Maven speak).
>>>> When would this be a problem? If a dependent module (someone else's
>>>> for example) depends on x.y.1 in their<version>   element I wouldn't
>>>> expect maven to pick a snapshot. If it did, then a lot of release
>>>> processes would be broken - picking snapshots instead of releases. So
>>>> that makes me think I've misunderstood what you're saying. Can you
>>>> expand a bit?
>>> Its during development and using tools like Sling's JCR Install or OBR.
>>> Remember that OBR obeys OSGi version comparison.
>>> In fact my proposal stems from early experience we had with OBR in
>>> Apache Sling where bundles were not updated to release versions because
>>> of x.y.z.SNAPSHOT>   x.y.z.
>>> Regards
>>> Felix
>>>>> FYI: This is how we do it in Sling:
>>>>> Regards
>>>>> Felix
>>>>> Am Mittwoch, den 16.03.2011, 09:20 +0000 schrieb zoe slattery:
>>>>>> Hi - as I work through making the changes to be able to release by
>>>>>> bundle we will need to start following an agreed version policy for
>>>>>> packages and bundles.
>>>>>> I've drafted something on the wiki (website). Please review it and
>>>>>> comment back to the list.
>>>>>> Thanks, Zoƫ

View raw message