On Jan 29, 2006, at 1:41 PM, David Blevins wrote:
On Jan 28, 2006, at 11:51 AM, David Jencks wrote:
On Jan 28, 2006, at 10:57 AM, Alan D. Cabrera wrote:
I've updated the trunk of Geronimo Specs to 1.1-SNAPSHOT. The
thinking is that we update the versions of all the spec jars in
tandem. The rational for that is that end developers will not
want to pick and choose what got updated in our collection of
spec jars but, instead, will just want the latest and greatest
version for the entire set.
IMO a more important reason is that we are aggregating all the
specs into an uber-spec-jar that contains everything. In order
for this jar to have a meaningful version all the things of which
it is built have to have the same version. In any case, I
certainly agree this is the right thing to do.
I see and understand those points, but I would like to add the
points that:
1. issuing new versions of jars that don't change creates a
confusing mess in public repos and classpaths.
2. snapshots and new jars off all the specs is a terrible way to
deal with one or two edge cases of jars that change.
But as opinions are cheap, I figured I'd actually revaluate where
we are at in concrete terms. I grabbed all the source from 2 years
ago, 10 months ago (near passing the cts), and now then stripped
out all the comments and diff'ed them. Here is what I found.
no code changes in 2 years:
- ejb
- j2ee-connector
- j2ee-deployment
- j2ee-management
- jms
- jsp
- jta
- servlet
no code changes in 10 months:
- activation
- jaxr
- qname (new)
- saaj (new)
- jaxrpc (new)
These two seem to have changed the most:
- j2ee-jacc (no change since M5)
- javamail (problem child)
IMHO, doesn't make sense to keep pushing new versions into the
public for stuff that doesn't change.
What do others think?
You left out the corba spec module, whose changes precipitated the
current brouhaha.
I'm fine with either:
1. dropping the uber-spec-jar entirely
2. keeping versions of every spec jar in sync.
I might be willing to consider another alternative if someone would
explain what it was, and how the uber-spec-jar version would be
determined after each of these individual events, each of which
requires re-releasing the uber-spec-jar:
individual spec jar A changes to say 1.1
individual spec jar B changes to say 1.1
individual spec jar A changes to say 1.2
So far I haven't seen any actual other proposals to (1) or (2)
thanks
david jencks
-David
