users@jersey.java.net

RE: [Jersey] Releasing Jersey 1.1.5 on the week of Jan 18th

From: Sudhakar Kumar <ksudhakar_at_live.com>
Date: Sat, 9 Jan 2010 12:10:29 -0500

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.
http://clk.atdmt.com/GBL/go/196390708/direct/01/