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 Mon, 28 Aug 2006 18:23:50 GMT

On Aug 28, 2006, at 10:51 AM, Dain Sundstrom wrote:

> but for maven users I don't think either matters since you can  
> simply use a version range dependency like this:
>
>     <dependency>
>       <groupId>org.apache.geronimo.specs</groupId>
>       <artifactId>geronimo-j2ee-connector_1.5_spec</artifactId>
>       <version>[1.0,)</version>
>     </dependency>
>
> This gives you the most resent published version of the connector  
> 1.5 spec (BTW I tried this out in the jencks project and it worked  
> perfectly).  Either solution for a maven user shouldn't be a problem.
>
> So I think that leaves us with the question what is going to be  
> easiest and quickest layout for us to release when we find a spec bug?

Seems like we could use that in our own pom.xml files and that would  
perfectly solve Kevan's original concern:

On Aug 22, 2006, at 6:24 AM, Kevan Miller wrote:
> 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.

It would also address my concerns from eight months ago (which had  
nothing to do with "easy" vs "hard, btw):

On Jan 29, 2006, at 1:41 PM, David Blevins wrote:
>  1. issuing new versions of jars that don't change creates a  
> confusing mess in public repos and classpaths.
>  2. snapshots and new jars off all the specs is a terrible way to  
> deal with one or two edge cases of jars that change.

Seems both concerns can be met.

-David






Mime
View raw message