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.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
A language that doesn’t affect the way you think about programming is
not worth knowing.
-— Alan Perlis
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
