On Dec 11, 2006, at 12:40 PM, Paul McMahan wrote:
On 12/11/06, Dain Sundstrom <[EMAIL PROTECTED]> wrote:
On Dec 11, 2006, at 10:52 AM, Paul McMahan wrote:
> I'm in favor of a single version for all specs. Versioning the
specs
> individually has some advantages but makes the release manager's
job
> more difficult since the tooling doesn't readily support that
> approach.
Um.. that's not true. Maven has full support for this. Also it
doesn't make the release manager's job harder.
Maybe I read too much into the wiki page that Kevan referenced, which
lists the following advantage for using a single version for specs:
- Release process is simple and can be fully automated with the
release plugin
And the following listed as a disadvantage of versioning the specs
individually:
- Releases are more difficult because the person performing the
release must be aware of any dependencies and must also rerelease
those jars. (eliminated with working version-ranges)
I thought you were referring to the Geronimo server releases. Yes
the above is true for releasing specs, but releasing specs is a very
rare thing since specs are rarely added or removed.
and lists as a supporting fact:
- Version ranges don't work several (most?) important maven plugins
Is the wiki page outdated or am I missing the point?
Nope that is accurate.
> I also believe having the specs all at a single release is
consistent
> with the approach we use in server/trunk, where the artifacts share
> the same geronimo version and when necessary a version number
can be
> included in the artifactId. Consistency has its benefits.
In that case, why not move specs into the server tree?
So a single version of specs can support more than one version of the
server. Would that not be the case with the 1.2 and 2.0-M1 versions
of the server?
I was being a devil's advocate. In general, once we release a spec
is should never change (i.e., should be 1.0 forever). Only in the
rare case where we find bugs in a spec would we release an update.
In that case, the specs would support all versions of the server that
need that spec, another project using our specs, and any user
applications using our specs.
-dain
