On Jan 29, 2006, at 4:45 PM, David Blevins wrote:
On Jan 29, 2006, at 3:13 PM, David Jencks wrote:
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 :-)
Sure. Everything has it's own version number which will be
incremented by one.
so you are thinking
individual spec jar A changes to say 1.1 >> uber version 1.1 :
contains mix of 1.0 and 1.1 versioned jars
individual spec jar B changes to say 1.1 >> uber version 1.2 :
still contains mix of 1.0 and 1.1 versioned jars
individual spec jar A changes to say 1.2 >> uber version 1.3 :
contains mix of 1.0, 1.1, and 1.2 versioned jars
?
To me this has the disadvantage that you have no way whatsoever of
telling what is in the uber spec jar from its version or contents
without binary comparisons. I consider this a fatal objection or at
least much more of a problem than incrementing the versions for all
jars simultaneously even though most have not changed.
So, I'm trying to add a requirement that the casual user be able to
figure out which jars went into each uber-jar we release from the
uber-jar itself.
thanks
david jencks
-David
