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.
-David
