users@jersey.java.net

[Jersey] Re: Jersey 2.0 final?

From: Marek Potociar <marek.potociar_at_oracle.com>
Date: Thu, 13 Jun 2013 21:12:12 +0200

On Jun 13, 2013, at 8:11 PM, cowwoc <cowwoc_at_bbs.darktech.org> wrote:

> On 13/06/2013 2:07 PM, Marek Potociar wrote:
>> On Jun 12, 2013, at 5:32 PM, cowwoc <cowwoc_at_bbs.darktech.org> wrote:
>>
>>> On 12/06/2013 11:30 AM, noky_at_nextbus.com wrote:
>>>> It looks like Jersey 2.0 has quietly reached "final" status as of May
>>>> 14, is that correct? At this point, can Jersey 2.0 be recommended for
>>>> production projects? We have started using Jersey 1.17 for a project
>>>> that is intended to go into production within the next couple months.
>>>>
>>>> I didn't see any official announcements and this page still shows that
>>>> Jersey 2.0 is not ready for production:
>>>> https://jersey.java.net/jersey20.html. However, the central repo seems
>>>> to show 2.0 is official now:
>>>> http://search.maven.org/#search|ga|1|org.glassfish.jersey
>>>>
>>>> Thanks! I've really been enjoying using Jersey, so grateful for all the
>>>> hard work that went into this!
>>>>
>>>>
>>>> Mike
>>> ... I hope not. I was just about to start contributing changes for concurrent unit tests. If what you say is true I'm going to have to wait another 2-3 years for this feature :(
>> ??? Why?
>>
>> Marek
>>
> Hi Marek,
>
> I am referring to the fact that Jersey 1.0 was released in December 2008 and I assume Jersey 2.0 will be released in 2013. In the interim 5 years, any enhancement request that required a breaking API change was put on hold.
>
> I'd be happy to be proven wrong on this point.

Here's my view on breaking changes (in Jersey APIs - packages "org.glassfish.jersey.*"):

We should try to avoid making breaking changes in general. Additions in the APIs are typically acceptable (less so in SPIs), we have to be however careful about signature changes or method removals. That said, if there is a good reason for making a breaking API change, we will certainly consider it. Ideally, any breaking change should be processed in 2 phases, spread into separate releases:

1. make the API deprecated and expose the new API that replaces the deprecated one
2. remove the deprecated API and keep only the new API

We're releasing new minor version typically every month. This means that we will allow some reasonable time (e.g. couple of months) for users who update their Jersey version frequently to adjust to the coming change.

So, yes, making a breaking change in Jersey 2 is not completely forbidden. There are however types of breaking changes that we will most likely not consider until the next major release. Those include mainly suggestions for complete removal of existing major features. OTOH, contributing a new major feature which could substitute an established major feature is not a problem at all in general. It's good if users have a choice so we welcome such contributions.

HTH,
Marek

P.S. As for JAX-RS APIs - packages "javax.ws.rs.*" - we cannot make any breaking changes in those.

>
> Gili