geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Hogstrom <m...@hogstrom.org>
Subject Re: [DISCUSS] specs versioning
Date Mon, 11 Dec 2006 21:13:21 GMT
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
matt@hogstrom.org



Mime
View raw message