On Jan 10, 2010, at 9:13 PM, Tatu Saloranta wrote:
> 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).
>
Agreed.
I will send another email either today or tomorrow suggesting another
proposal based on useful feedback so far.
Paul.
> 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 +-
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>