Jason van Zyl wrote:
On 17-Jul-08, at 8:08 PM, Ralph Goers wrote:
Michael McCallum wrote:
why not just specify the dependencies with version ranges, if you do
there is no need to rewrite anything it just works...
My builds never use version ranges. We require that builds be
reproduceable at any time in the future. Version ranges don't
guarantee that.
Version ranges by themselves don't guarantee anything, but I think
what you're saying is that they don't guarantee a released versions
artifacts being reproducible.
The way OSGi works is that the ranges play a part at build time and
runtime. During the time working up to a release ranges are useful to
allow flexibility of testing new versions of code, much like the way
snapshots work and at the time of release you can choose to lock the
versions down. If you lock the versions down then there is no
flexibility in the runtime to accept new versions. Oleg and I have
been trying to work out a way where we can have our cake and eat it
too: allow the flexibility of variable runtime versioning while
keeping an exact list of what actually worked for a release. I think
anyone who has been doing this for a while realizes that once a
project has been QA'd it makes no sense to allow everything to vary. I
think it's a hybrid of these approaches that will allow the most
utility across build and deployment.
That pretty much sums up what I am saying. I view an OSGi bundle a
little differently than a maven project build primarily because the
bundle presumably has a larger granularity. In both cases though, I
would want a version upgrade to be deliberately controlled. Even while
in development we don't use version ranges. If we choose to upgrade the
version of an artifact we do it in our third party pom's
dependencyManagement and then retest. With OSGi I'd imagine doing more
or less the same thing by installing the new bundle and testing long
before QA. However, this would be done deliberately, not automagically.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
