On Sun, Jan 10, 2010 at 8:12 AM, Trolly Rogers
<trolly.s.rogers_at_gmail.com> wrote:
> I too didn't realize (seems obvious now) that Jersey incorporated the JAX-RS
> version into its version #. I'm on the side of the fence that thinks
> introducing a 2.0 or 3.0 where the main intent is to convey a new versioning
> scheme will lead to more confusion. Seems natural to me that a, let's say,
> 1.2 of Jersey which drops the correlation of JAX-RS versions would be less
> confusing than introducing a new major version.
>
> In general, I've always thought of spec versions independently of the
> versions of their implementations. If I want to know which servlet spec
> tomcat 5.5 implements, I just look at
> http://tomcat.apache.org/whichversion.html.
FWIW, I was not arguing against getting rid of rigid dependency (i.e.
that jersey would have to have same version as jax-rs api).
However, I would expect that when a major API change (Servlet 3.0)
occurs, containers would likewise have major version bump. That is
what Jetty does.
That is: when JAX-RS major version changes, yes, I would fully expect
Jersey (core) major version to advance. That is by definition a major
version change trigger (for Maven et al).
But I do not think that Jersey has to have _same_ major version as
spec. Right now that could be done, and would be convenient. But
that's just a nice to have IMO.
So I don't see any reason not to get to 2.0 for JAX-RS 2.0. Major
version changes for standard APIs are big things. If they weren't,
they would be minor udates (1.0 -> 1.1).
Existence of extensions beyond core JAX-RS (esp. client side)
complicates things obviously. I would think that it would make good
sense to separate client-side package more from core and server side.
And client versioning should not be artifically kept in sync if (when)
it develops at significantly faster pace. So there is nothing wrong
with having, say, Jersey-client 4.0, that would use JAX-RS 2.0 API.
-+ Tatu +-