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
