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. And as a developer (at least for me) a single version is more intuitive, evidenced by my recent snafu where I created the initial version of jsp 2.1 spec at 1.1-SNAPSHOT. Thankfully Jason keeps a very close eye on things and suggested using 1.0-SNAPSHOT instead.
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. Best wishes, Paul On 12/11/06, Kevan Miller <[EMAIL PROTECTED]> 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
