On 13/06/2013 3:12 PM, Marek Potociar wrote:
> 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.
>
This is welcome news indeed! Thank you for the clarification.
Gili