You oversee one point: My proposal is *not* a new creation of definition, it
just adds an indicator to the name of the jersey bundle indicating which
specification (JAX-RS 1.1) it is implementing. In terms of Microsoft, it
would be "jersey-vista" compared to "jersey-xp", and I doubt you would have
something against that, as vista and xp are as clearly separate things as
JAX-RS 1.0 and 2.0 would be. Also, the proposal was only made due to the
fact that there *are* programmers that like to see that dependency (while I
personally don't need that since I am able to look into a POM file's
dependency section to find out that information). My original proposal was
to *not* fumble around with versions at all but just apply the Maven Best
Practices as they are.
Regards
Markus
From: Sudhakar Kumar [mailto:ksudhakar_at_live.com]
Sent: Samstag, 9. Januar 2010 18:10
To: users_at_jersey.dev.java.net
Subject: RE: [Jersey] Releasing Jersey 1.1.5 on the week of Jan 18th
Innovative thoughts Markus. But. . .
So what next? Relate Jersey release with the JRE release?
I think as developers we have a responsibility to understand and decide the
version of software we need to use in development and assembly process. It
is an important decision. If we need to facilitate the process of making
this decision, then we need to do so through appropriate documentation - say
within the download site.
Versioning is not limited to JAX-RS and Jersey. My two cents is to not
create a new definition of 'versioning' specific to jersey and jax-rs. These
are two distinct entities, just as jersey and jre.
> From: markus.karg_at_gmx.net
> To: users_at_jersey.dev.java.net
> Date: Sat, 9 Jan 2010 09:44:11 +0100
> Subject: RE: [Jersey] Releasing Jersey 1.1.5 on the week of Jan 18th
>
> Tatu,
>
> I think I have found a solution that will make all of us happy and want to
> propose it as a concensus. But before I propose it, first let me answer
your
> point:
>
> Sync'ed versions imply one severe problem: Jersey is not just JAX-RS, it
> also contains lots of other functionality. What will you do if there is no
> JAX-RS progress for long time, but there are heavy changes in the other
> areas of technology which would mandate a major or minor version change?
> Currently Jersey will reflect this using the two left over version pieces
> (bugfix and build), but this means those cannot be used for what they are
> there: What will you do in case of a real bugfix...? You wouldn't just
have
> left over a peace of information to reflect it! Following this
argumentation
> there just is no space left over (unless you extend the version number to
> SIX pieces, and here comes my proposal into play).
>
> My proposal is, to move JAX-RS's version number into the NAME part of the
> file, so the name will be sync'ed with the JAX-RS version number, while
> Jersey's own version number has left it's full four parts for it's own and
> intended use. Example:
>
> <artifactId>jersey-jaxrs-1.2</artifactId>
> <version>3.4.5-6</version>
>
> will be Build No. 6 of Jersey Release 3.4's Bugfix No. 6, which is the RI
of
> JAX-RS Release 1.2 !
>
> As a JAX-RS version change actually is a specification change, it makes
> pretty much sense that the artifactId will change. Just as Microsoft's OS
> was no more called Vista but Seven after the SDK's API specification
number
> changed, while there was no rename just for the ServicePacks and BugFixes
> before (and no, I don't think that technically Windows Seven is worth to
> change version from NT6 to NT7, but rather would have chosen a minor
number
> of NT6.5 ;-) ).
>
> Ain't that the non-plus-ultra solution?
>
> It is 100% Maven 2 compatible (as Maven allows virtually anything inside
of
> the artifactId, as it is a different coordinate, separated from the
> version), and the resulting file name would look like this:
>
> jersey-jaxrs-1.2-3.4.5-6.jar
>
> So there is no more need to neither break sync'ing with JAX-RS, nor for
> artificially increasing the version to 3.0 without a real change!
>
> The drawbacks would be: One cannot say "I want ANY Jersey" without
> specifying the JAX-RS version number. But hey, would that make any sense
at
> all? I mean, even a minor change in JAX-RS should imply a careful decision
> whether to actually use it or not, and not let it open to Maven, while it
> makes pretty much sense that inside that manually chosen specification
> version, Maven shall automatically select it's latest RI.
>
> Regards
> Markus
>
> > -----Original Message-----
> > From: Tatu Saloranta [mailto:tsaloranta_at_gmail.com]
> > Sent: Freitag, 8. Januar 2010 20:07
> > To: users_at_jersey.dev.java.net
> > Subject: Re: [Jersey] Releasing Jersey 1.1.5 on the week of Jan 18th
> >
> > On Fri, Jan 8, 2010 at 5:50 AM, Tim Edwards
> > <Edwards.T_at_cambridgeassessment.org.uk> wrote:
> > > It might be that I was missing the obvious but personally I never
> > realised
> > > there was a correlation between JAX-RS and Jersey versions.
> >
> > Perhaps I am in minority, but I would expect Jersey to somewhat follow
> > JAX-RS versioning scheme, given that it is currently feasible. If
> > there were other major changes that would warrant major version
> > upgrade, then this would have to change.
> >
> > So my opinion is that (a) Maven-style versioning makes sense -- major
> > version for major non-compatible changes, minor for additional
> > functionality (backwards compatible), and so on and (b) having Jersey
> > version relate to JAX-RS version is a nice to have thing too.
> > And obviously if/when JAX-RS API change to 2.0 is a major incompatible
> > one, it should bump Jersey into new version anyway.
> >
> > -+ Tatu +-
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> > For additional commands, e-mail: users-help_at_jersey.dev.java.net
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>
_____
Hotmail: Free, trusted and rich email service. Get it
<
http://clk.atdmt.com/GBL/go/196390708/direct/01/> now.