It sounds like there is agreement that the new JAX-RS stuff should come out sooner rather than later. The remaining issue is what to label the release. Is this correct?
Personally, I agree with Sergey on this. The JAX-RS bump to 0.8 does not warrant being a 2.2 release on its own merits. The spec is still in flux and the users of the API are likely to expect some changes as the spec matures to a 1.0. If there are other changes that break compatibility in the more stable parts of CXF then a bump to 2.2 would be warranted. -----Original Message----- From: Sergey Beryozkin [mailto:[EMAIL PROTECTED] Sent: Thursday, July 03, 2008 8:44 AM To: [email protected] Subject: Re: JAX-RS version and 2.1.2 I doubt a CXF JAX-RS 0.6 to 0.8 upgrade (which is by default is a breaking change as the JAXRS spec is a moving target) deserves a 2.2 mark. If it were CXF JAX-RS 0.8 to 1.0.final then yes, it would probably make sense to 'mark the occasion' but not because of the potential breaking changes between 0.8 and 1.0-final. It's not about CXF-specific breaking changes, it's about users depending on a the jax-rs api which is still under development - as such they should be prepared to recompile their code Cheers, Sergey ----- Original Message ----- From: "Brice" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Thursday, July 03, 2008 1:28 PM Subject: Re: JAX-RS version and 2.1.2 > Actualy I'm not saying to wait for 2.2. I'm rather proposing to label the > next release with your updated JAXRS work a 2.2, and the next big release > which is "*quite ways away*" be labeled a 2.3. > > > > On Thu, Jul 3, 2008 at 11:33, Sergey Beryozkin <[EMAIL PROTECTED]> > wrote: > >> While it's all about the good classical versioning scheme, I'm not >> convinced >> postponing jax-rs updates up untill 2.2 is a practical idea. >> 2.2 will probably be released some time in the end of the year and for cxf >> users who prefer to stick for whatever reasons to its jax-rs implementation >> is not really acceptable. >> >> Note that JAX-RS itself is still in its 0.X version. Surely it's normal to >> expect that changes from >> 0,7 to 0.8 and up until 1.0 will cause some breaking changes. >> >> As such I'm against postponing it until 2.2 >> >> Cheers. Sergey >> >> >> ----- Original Message ----- From: "Brice" <[EMAIL PROTECTED]> >> To: <[email protected]> >> Sent: Wednesday, July 02, 2008 9:50 PM >> >> Subject: Re: JAX-RS version and 2.1.2 >> >> >> Well, I think it shouldn't be a 2.1.2, the last number should be only >>> incremented when the release is about fixes and doesn't break things. >>> >>> In my point of view the next version should be a 2.2 as it seems to break >>> things even if it is only on the jaxrs spec, and then a 2.3 version could >>> be >>> the next one as it seems to bring even more changes. >>> >>> While I think it cannot be entirely applied there, I'll tell you >>> versionning >>> scheme I had on some past project: >>> X.Y.Z-R >>> Where X is mean for breaking changes of the API, Y for additions to the >>> API, >>> Z for internal code changes without any API modification, and R for >>> patches >>> of the current revision. >>> >>> >>> >>> >>> >>> >>> On Wed, Jul 2, 2008 at 20:08, Johnson, Eric <[EMAIL PROTECTED]> >>> wrote: >>> >>> I'm +1 on including the changes in 2.1.2. Sergey's comments lead me to >>>> believe that the changes will not have an impact on a majority of users >>>> of the JAX-RS stuff. >>>> Also, I agree with Benson that people looking for stability are not >>>> using the JAX-RS stuff. The spec is still a moving target. >>>> >>>> >>>> -----Original Message----- >>>> From: Benson Margulies [mailto:[EMAIL PROTECTED] >>>> Sent: Wednesday, July 02, 2008 11:22 AM >>>> To: [email protected] >>>> Subject: Re: JAX-RS version and 2.1.2 >>>> >>>> I'm +1 on 2.1.2. People who really care about stability are, I suspect, >>>> sticking with 2.0.x. >>>> >>>> A compromise would be to announce the intention to include in in 2.1.3, >>>> and try to really push down the defect count in 2.1.2. Then people who >>>> want to stay on the old spec could stay on 2.1.2. >>>> >>>> >>>> On Wed, Jul 2, 2008 at 9:28 AM, Daniel Kulp <[EMAIL PROTECTED]> wrote: >>>> >>>> > >>>> > Sergey's commit brings up an interesting topic for discussion: >>>> > >>>> > In general, when doing patch releases, I've tried to keep the impact >>>> > to a bare minimum. I have ported new features to the patch branches, >>>> but pretty >>>> > much only if it doesn't affect existing usage. Sergey has done a >>>> > fantastic job of updating the JAX-RS stuff to the latest 0.8 spec and >>>> > it would be good to get people to change to using that. However, it >>>> is a >>>> > change that could affect existing code. So, should that be part of >>>> 2.1.2 >>>> > or wait for 2.2? >>>> > >>>> > Pros/cons of adding to 2.1.2: >>>> > Pro: It's significantly better and has a bunch of bugs fixed >>>> > Pro: It's closer to the final spec (although the spec is still >>>> > changing) >>>> > Pro: Going forward, people will need to migrate to it anyway >>>> > >>>> > Con: it does affect existing apps >>>> > >>>> > >>>> > The main con to making it 2.2 only is that 2.2 is quite a ways away. >>>> > People have been asking for some of this stuff so making them wait >>>> > that long could be an issue. >>>> > >>>> > Anyway, I'd like peoples thoughts on this. I've cc'd the users list >>>> as >>>> > well as I'd really like the users opinions as well. If the users >>>> are >>>> > willing to take the migration hit, I'm more than OK with putting it >>>> > for 2.1.2. >>>> > >>>> > >>>> > --- >>>> > Daniel Kulp >>>> > [EMAIL PROTECTED] >>>> > http://www.dankulp.com/blog >>>> > >>>> > >>>> > >>>> > >>>> > >>>> >>>> >>> >>> >>> -- >>> Brice Dutheil >>> >>> >> ---------------------------- >> IONA Technologies PLC (registered in Ireland) >> Registered Number: 171387 >> Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland >> > > > > -- > Brice Dutheil > ---------------------------- IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
