geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Blevins <david.blev...@visi.com>
Subject Re: [VOTE] Specs organization, versioning, and releasing
Date Tue, 22 Aug 2006 16:45:53 GMT

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?

Any thoughts?

-David


Mime
View raw message