geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevan Miller <>
Subject Re: [VOTE] Specs organization, versioning, and releasing
Date Tue, 22 Aug 2006 02:13:39 GMT
As long as we have inter-dependencies between specs (e.g. javamail  
depends on activation; jaxrpc on saaj, qname, and servlet; and  
especially geronimo-spec-j2ee depends on everything), I'm not  
convinced that this really makes things any better...

I agree that your plan is better than the previous plan for multiple  
trunks, but I'm not convinced that either plan is actually making  
things simpler...

If I understand your proposal, tags/geronimo-spec-jaxrpc-<jax- 
rpcversion>/pom.xml will specify the tagged versions of saaj, qname,  
and servlet upon which it depends? So, haven't we just split apart  
the specification of these version dependencies from a single pom.xml  
into multiple poms? Is this really making things simpler?

I think the source of complexity is the granularity of versioning  
we're trying to apply to specs... I wonder if the simplest course of  
action is to stop releasing individually versioned specs, and instead  
always release all specs. When an update to the 1.2.0 specs are  
required, release a 1.2.1 version of all specs (even if some of the  
1.2.1 versions are identical to their 1.2.0 version).


On Aug 18, 2006, at 7:53 PM, Jason Dillon wrote:

> 1.  Each spec will no longer be split up into trunk+branches+tags.  
> There will instead be one trunk+branches+tags for all specs laid  
> out as follows:
>     specs/trunk/pom.xml
>     specs/trunk/<artifactId>
>     specs/tags/<artifactId>-<version>
>     specs/branches/
> 2.  Each plugin will continue to have its own version and will be  
> released independently.
> 3.  The top-level will have it's own version, which will remain  
> independent.  When there is a major configuration change in that  
> pom, the version will be changed and the pom will be republished.
> 4.  Releasing will be done with the maven release plugin ('mvn  
> release') and should occur at a stable point after any major change  
> to a spec module.
> 5. Change all module directories to match artifactIds.
> 1.  one trunk allows the entire set of specs to be checked out all at
>     once and built all at once.
>  * * *
> [ ] +1 Allow changes
> [ ] 0  No opinion
> [ ] -1 No, leave the specs asis (provide rationale)
> --jason

View raw message