Imran M Yousuf wrote:
>> I would be interested in hearing feedback on the rate of which we should
>> evolve the Jersey APIs. We will need to make some package name changes and
>> clean up the boundaries between modules. Part of the motivation for this is
>> to make Jersey OSGi-enabled. Given our schedule this is likely to happen
>> after 1.0.0.0 as a 1.0.x.y release, say 1.0.1.y, where 'x' signifies a
>> change in the Jersey APIs and 'y' signifies a change in implementation (for
>> Jersey to be a 1.1 release requires that there be a JAX-RS 1.1 version).
>>
>
> To be honest this time around the "0.10" version was creating some
> discomfort for me, it would be more confortable if version were like
> "1.0.x.yy" with x and y signifying the same meaning as mentioned by
> you.
Unfortunately we cannot call things 1.0 yet. Every release corresponded
to API changes (311 and Jersey) and we did not have the resources to do
stable point releases while also implementing/tracking changes. So the
best i could do was align the Jersey version with the API version and
release regularly about every 6 weeks.
> I would like to see frequent stable 'yy' releases to make the
> latest fixes and implementations improvements public instead of asking
> to use SNAPSHOTS to avail them.
>
We have our maven release process such that it is nearly automated. I
think Jakub has things set up so it may almost be possible to tag,
convert, build and deploy in one or two steps.
However, there are some additional factors to releasing. Every time we
release we need to test, and this still takes time, so we need to
automate tests for the examples (adding stuff to the test directory,
this can also serve as examples of how to use the client API). So for
the spring example i encourage you to use the unit test framework for
the client interactions :-)
In addition we need to set up a Hudson matrix job to run the jersey
tests and examples on a number of platforms and JDK versions.
> Also in this regard for samples, I would like to add "1.0.x.yy.zz" in
> order to incorporate new and richer samples as they are integrated
> into trunk.
>
If we release regularly and often i am not sure if this is really
necessary i.e. for testing/experimental purposes the SNAPSHOT build can
be used. My preference is to keep all Jersey related modules in sync and
released at the same time rather than spinning some modules faster than
others. It is easier to manage and there is a clear indication that all
modules of the same version have been tested together. If some modules
need to be spun at different rates then i think it implies that module
should be a separate project.
Paul.
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109