On Jan 29, 2006, at 2:35 PM, David Blevins wrote:
On Jan 29, 2006, at 2:01 PM, David Jencks wrote:
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)
I think we should just push new version of a spec jar at an
appropriate time when said jar changes. For the uber-spec jar we
can just push a new version when a dep spec jar changes.
Seem reasonable?
To me this is not a proposal until you specify what the uber spec jar
revision is after each of the changes I mentioned. An algorithm
would be even better :-)
So, not yet :-)
thanks
david jencks
-David
