IMHO I like option 3 which is both option 1 and 2. First, I think
all SPECs should be versioned independently as not everyone is
interested in all the specs. If, for instance, the Tomcat dudes
decide to pick up anything we have they would only be interested in a
subset and shouldn't be forced to consume the whole Java EE banana.
So, in that light I think they should all be versioned separately.
We should probably have a separate uber spec project that pulls in a
set of versioned specs and releases them as a set so that people that
want the whole enchilada can get them. The uber approach would only
be compiling a set of released specs (which were released separately.
For this proposal...I'd say release them individually and make the
uber spec as the next step. IMHO small largely immutable specs make
sense to me.
On Dec 11, 2006, at 1:13 PM, Kevan Miller wrote:
The versioning policy for our geronimo specs has been floating
around for a while now. I'd like to see this issue resolved.
There have been two approaches discussed
1) Single version -- all specs are released under the same version
number.
2) Separate version -- each spec is versioned separately from the
other specs.
Dain created a review of the two proposals in the wiki -- http://
cwiki.apache.org/confluence/display/GMOxDEV/Spec+Versioning I think
you can quibble over a few of the details, but it does a good job
at summarizing the issue.
IMO, there are going to be drawbacks no matter which approach we
take. However, I'm going to be happy with either approach as long
as we reach a *decision*. I'd prefer that we reach consensus on
this discussion thread. However, if necessary, we can vote on the
issue.
Personally, I think we should use a single version for releasing
our specs. I think this makes it easier for us as developers in
managing spec releases. I think users will find it easier to
collect a consistent set of specifications. I think these benefits
outweigh concerns over the lack of flexibility and the wasteful
aspects of re-releasing unchanged specifications.
I suppose there's a hybrid option where we release separate
versions, now, and move to a single version policy (2.0?) for our
next release.
--kevan
Matt Hogstrom
[EMAIL PROTECTED]
