geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Dillon <ja...@planet57.com>
Subject Re: [VOTE] Specs organization, versioning, and releasing
Date Tue, 29 Aug 2006 00:50:43 GMT
I don't think that using version ranges really helps make anything  
easier or simpler.

How is it confusing to have just one version number for all specs?   
Anything else seems to induce much more confusion, for us and them.

If the confusion is... "why is there a new version for a jar that did  
not change" I point you back at my example of Geronimo and releasing  
bug fix versions... where say 80% of the modules will have a new  
version but no changes.  Does this also confuse users?  If so, then  
we need to educate our users and not try to dance around their  
ignorance and complicate our build release management.

--jason


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

> I am starting to get dizzy from this discussion...
>
> I remember the original argument for switching to individually  
> versioned specifications was to avoid republishing specs like  
> javax.ejb repeatedly as it confused users to have new version  
> numbers that don't change.  The counter argument is that having  
> lots of different version numbers is difficult for users as they  
> will have to know the version of every jar.
>
> I think both concerns are important, 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?
>
> -dain
>
> On Aug 27, 2006, at 4:50 PM, Jason Dillon wrote:
>
>> I've implemented #5, which was to restructure to use the same
>> directory and artifactIds... I renamed the directories to match.
>>
>> I think we need to have another round of discussion on how to handle
>> the versioning.
>>
>> I'm starting to lean heavily towards having *one* version for  
>> *all* of
>> the specs.  I don't care too much that if spec A makes a change that
>> we release new versions of all of the other specs.  It is actually
>> similar to the server, when a bugfix release is made, a bunch of
>> modules will have no change since the last version, but we release
>> them anyways because it is simpler for use to manage, and easier for
>> users too, since they just need to know one version number... not the
>> version number of each module.
>>
>> IMO, less version numbers to manage is easier... and better.  The  
>> side
>> effect is that more artifacts get released when we cut a new version.
>> But I don't see that we are going to be making tons of these spec
>> releases... so I don't see any harm in the additional artifacts.
>>
>> So, my recommendation is to use one version for all of them.  I
>> believe this will be best in the short to medium term at least,  
>> and if
>> we find that it not working for the long run, then we can revisit
>> later.  But right now I'd like to get a consistent release of these
>> artifacts so we can remove the need for the bootstrap step to check
>> them out and build them.
>>
>> I'd like to discus for a few days, create a new proposal, vote and
>> then implement in the near future.
>>
>> Comments?
>>
>> --jason
>>
>>
>>
>> On 8/18/06, Jason Dillon <jason@planet57.com> wrote:
>>> PROPOSAL:
>>>
>>> 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.
>>>
>>> MOTIVATION:
>>>
>>> 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
>>>
>>>
>


Mime
View raw message