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 03:44:55 GMT
I still think that releasing each spec module individual adds  
complexity... and IMO is not worth it.

--jason


On Aug 28, 2006, at 8:41 PM, David Blevins wrote:

>
> 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