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 19:48:13 GMT

On Aug 22, 2006, at 12:45 PM, David Blevins wrote:

> On Aug 22, 2006, at 6:24 AM, Kevan Miller wrote:
>> 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-saaj.
>> 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 geronimoSpecsJaccVersion
>> 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
> 6) tag branches/1_1/pom.xml
> 7) release pom.xml
> If the version information for any given module is only contained  
> in the parent, we have to release the parent when we release the  
> module.
>> 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.
> Kevan, this question was directed at you.
> On Aug 21, 2006, at 10:44 PM, David Blevins wrote:
>> This just came into mind.  Any thoughts on what we'd do for the  
>> specs that are javaee 5 only versions (corba, servlet, soon jta  
>> and ejb, etc.) and the ones that overlap between j2ee 1.4 and  
>> javaee 5 like jms, jca and jacc?

Something like:

specs/branches/1.1 will remain a more or less "pure" 1.4 level of the  

specs/branches/1.2 would contain the 1.4 specs and roll-in the Java  
EE 5 specs as we need and implement them. The geronimo-j2ee_1.4_spec  
(if we keep it) would contain only 1.4 versions of specs. Java EE 5  
specs would stand on their own (e.g. geronimo-ejb_3.0_spec-1.2.0). If  
we wanted, we could introduce a geronimo-javaee_5_spec (which  
includes new specs).

specs/branches/2.0 would contain only Java EE 5 specs (and any non-EE  
specs that we're moving forward/maintaining).

There is of course, duplication of source (just like you have anytime  
you branch...) and problems might need to be fixed in (and released  
from) multiple branches).


View raw message