On 1/29/2006 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.
<lots-of-good-analysis/>
IMHO, doesn't make sense to keep pushing new versions into the public
for stuff that doesn't change.
Think of what the alternative is that you are asking the end developer
to cope w/. He must grok what is the current correct collection of
versions are. Even if all the APIs mature and their version numbers
never change thereafter, there will be confusion when we say everything
is 1.0 except for CORBA which is 1.3 and JavaMail which is 1.545. We
should also consider the situation when we accommodate new JSRs as well.
IMHO, people won't care about the new versions so long as they have a
single version to remember.
Regards,
Alan
