On Tue, Jan 12, 2010 at 9:19 AM, Markus Karg <markus.karg_at_gmx.net> wrote:
...
>> I think the main (and perhaps only) problem would be inconvenience, if
>> you have to depend on Jersey.
>> Downstream systems would then have to update their dependencies to
>> either include both older and newer version, or to upgrade to newer;
>> but these without getting any benefits.
>
> But solving issues like this is exactly what Maven's version ranges are good
> for: You can set e. g. [1.1, 1.1.5][3.0, 4.0) - or even easier: [1.1, 4.0)
> as Paul guarantees there will be nothing between 1.1.5 and 3.0 - for example
> to designate the API you want to bind against, and Maven will choose the
> latest bug fix automatically -- and thanks to the second interval, you even
> won't notice the step from 1.1.5 to 3.0. So if you copy the above range to
> your project now, your concerns will be solved.
Yes and no. :-)
Yes, when you know meaning of versions. But no, since you can not
forecast in advance what the semantics are (not even necessarily for
packages you own, much less for packages others own).
Major version bump could be something that renders new version incompatible.
You only know once definition of release is available, after release
is done, or shortly before it is being made. You can of course have
plans on kinds of compatibility levels you try to achieve, but they
are just plans, and most OS projects would choose "right thing" over
"previously planned", breaking compatibility whenever it is deemed the
right thing to do.
It would work if one did know what future major versions mean. I just
don't think this happens often.
It also depends on how conservative one wants to be: one potential
view is that you just specify minimum version you need, and hope
future versions are backwards compatible. And/or that by time actual
incompatibilities arise, your package has evolved much further and you
have had time to clarify dependencies. This can work if your package
is actively evolving, and your users are quick to upgrade to newer
versions.
-+ Tatu +-