On 16/03/2011 19:28, Felix Meschberger wrote:
Hi,
Am Mittwoch, den 16.03.2011, 16:49 +0000 schrieb Jeremy Hughes:
On 16 March 2011 11:22, Felix Meschberger<[email protected]> wrote:
Hi,
Good thing !
Some remarks:
Re. Bundles: A bundle should never exist as a non-SNAPSHOT version in
the trunk (except during the short period of time during which Maven
generates the version tag). As such immediately after a release the
bundle version switches to x.y.(z+1)-SNAPSHOT.
The suggestion is to only move to x.y.(z+1)-SNAPSHOT when the first
change is made to trunk. If trunk is identical to the last release,
then the version in the pom is left alone.
Believe me, this ain't gonna work ... We are all humans and prone to
make mistakes, i.e. forget switching the version.
I think it's possibly less error prone than you think. Say you have just
made a change in bundle A, if the version is _not_ switched, Bundle B
which depends on A will not pick up the change until the dependency
version in B is changed _and_ the version of A is changed. This will be
obvious quite quickly.
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ë
