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 13:24:55 GMT

On Aug 22, 2006, at 1:37 AM, David Jencks wrote:

> On Aug 21, 2006, at 9:21 PM, David Blevins wrote:
>> On Aug 21, 2006, at 7:13 PM, Kevan Miller wrote:
>>> 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?
>> That'd be right.  I'm not sure how complicated that is, though.   
>> None of those specs have changed in a year.  Can you give an non- 
>> hypothetical example of something that does change and causes this  
>> problem that isn't the J2EE uber-jar?

Well, the current activation spec is at version 1.1. When that  
version was bumped from 1.0 (or 1.0.x), you'd have needed to know/ 
remember to change the poms in the following specs: geronimo-spec- 
j2ee, geronimo-spec-javamail, geronimo-spec-jaxr, and geronimo-spec- 

A question for you, Jason: If someone wants to build our released  
specs from source, what's the process?

> Maybe I don't understand the proposal, but otherwise IIUC every  
> time we've found a problem in e.g. the jacc spec we'd need to  
> release every spec jar, and update all the versions.  I guess we do  
> this with a lot of geronimo jars going e.g.  from 1.1 to 1.1.1 but  
> I think having a lot of identical-contents spec jars would be too  
> confusing.

No, I don't think that's what is happening (at least not in theory),  
but I've never actually "released" specs. So, I may be mistaken...

Current Process for updating jacc

1) Update branches/1_1/pom.xml with new geronimoSpecsVersion and new  
2) Update jacc spec sources
3) Build all specs
4) Release jacc and uber-jar spec
5) tag branches/1_1 as tags/1.1.x

Current Proposed Process

1) Update branches/1_1/geronimo-j2ee/pom.xml with new uber-jar spec  
version and new jacc spec version
2) Update branches/1_1/geronimo-jacc/pom.xml with new jacc spec version
3) Update jacc spec sources
4) Build jacc and uber-jar (build seperately or together?).
6) Release jacc
7) tag jacc-<version>
8) Release uber-jar
9) tag uber-jar-<version>

Single-version Proposed Process

1) Update branches/1_1_/pom.xml with new specs version
2) Update jacc spec sources
3) Build all specs
4) Release all specs
5) tag branches/1_1 as tags/1.1.x

I don't see that releasing identical content spec jars are  
necessarily confusing (as you point out, we essentially do it with  
every Geronimo release). Less confusing to have only a single version  
to worry about... What's the latest release 1.1.x geronimo specs? Use  
that for all of my j2ee 1.4 spec dependencies. Seems simpler than  
knowing the latest jacc spec is at version x and the latest servlet  
2.4 spec is at version y.


View raw message