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:43:29 GMT
My preference is to treat specs like any other top-level project,  
like server, xbean, gbuild, etc...

and that to means one version for all of the modules.

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