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