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, 29 Aug 2006 03:41:55 GMT

On Aug 28, 2006, at 7:49 PM, Jason Dillon wrote:

> The pom is part of the release.
>

On Aug 28, 2006, at 7:46 PM, David Blevins wrote:
> The only reason we've had to re-release these is because the poms  
> of a couple have changed.  We can fix that with version ranges.

Meaning, if we add version ranges to our poms when they refer to  
other specs, we don't need to re-release them when those other specs  
change.

-David

> --jason
>
>
> On Aug 28, 2006, at 7:46 PM, David Blevins wrote:
>
>>
>> On Aug 28, 2006, at 5:50 PM, Jason Dillon wrote:
>>
>>> 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.
>>
>> I've intentionally not made any statements of what is "easy" and  
>> you're countering arguments I've never made.
>>
>> The following specs haven't changed in a 1-2 years and don't need  
>> to be released:
>>
>> geronimo-ejb_2.1_spec
>> geronimo-j2ee-connector_1.5_spec
>> geronimo-j2ee-deployment_1.1_spec
>> geronimo-j2ee-jacc_1.0_spec
>> geronimo-j2ee-management_1.0_spec
>> geronimo-jaxr_1.0_spec
>> geronimo-jaxrpc_1.1_spec
>> geronimo-jms_1.1_spec
>> geronimo-jsp_2.0_spec
>> geronimo-jta_1.0.1B_spec
>> geronimo-qname_1.1_spec
>> geronimo-saaj_1.1_spec
>> geronimo-servlet_2.4_spec
>>
>> The only reason we've had to re-release these is because the poms  
>> of a couple have changed.  We can fix that with version ranges.
>>
>>
>> -David
>>
>>> --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