Hi
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.
Agreed
(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.
Agreed
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:
http://sling.apache.org/site/version-policy.html.
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.
http://aries.apache.org/development/versionpolicy.html
Thanks, Zoë
