geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alan D. Cabrera" <...@toolazydogs.com>
Subject Re: [PROPOSAL] Next milestone release (M4?)
Date Tue, 29 Mar 2005 18:09:46 GMT
1. Agreed.  This should be a non-issue shortly.
2. This is a tall order, IMHO.  I think that this is a goal that should 
be vigorously sought but I don't think that it should stop a milestone 
release.  Maybe a v1.0 release, I'll grant you that.


Regards,
Alan


David Jencks wrote:

> I will -1 any milestone release proposal until these issues are taken 
> care of in a way I consider satisfactory:
>
> 1. circular build dependencies between openejb and geronimo.  I've 
> proposed a simple solution that would not involve moving any code and 
> will repeat the suggestion if requested.  A better solution would move 
> assembly out of modules.
>
> 2. dependence on privately patched jars or even snapshots of other 
> projects.  Currently the only private patch I know of is of Jetty and 
> I hope to resolve this shortly.  I would definitely prefer that we 
> minimize the number of snapshots of other projects, especially axis.
>
> In addition I would prefer that we move to xmlbeans 2 or provide a 
> convincing argument why not.
>
> thanks
> david jencks
>
> On Mar 29, 2005, at 9:12 AM, Geir Magnusson Jr. wrote:
>
>>
>> On Mar 29, 2005, at 11:33 AM, Alan D. Cabrera wrote:
>>
>>>
>>>
>>> Geir Magnusson Jr. wrote:
>>>
>>>>
>>>> On Mar 29, 2005, at 10:40 AM, Jeremy Boynes wrote:
>>>>
>>>>> -1
>>>>>
>>>>
>>>> We'll ignore this as it isn't a vote :)
>>>>
>>>>> Whilst I agree with the intention, we do not have a process 
>>>>> defined that  would allow us to generate a reproducable release. 
>>>>> This led to several of the issues with the last M3 release that 
>>>>> ultimately made is unusable.  We must fix this before we can 
>>>>> release another version.
>>>>>
>>>>> Specific things I think we need include in such a process:
>>>>> * an mechanical process for producing the candidate binaries that 
>>>>> can be
>>>>>   executed against any SVN tag. This would reduce the potential for
>>>>>   minor variations by people doing the release that would result in
>>>>>   potentially different binaries
>>>>>
>>>>
>>>> Yes
>>>>
>>>>> * elimination of SNAPSHOT dependencies - these are by nature 
>>>>> ephemeral
>>>>>   making it impossible to later regenerate the same distribution
>>>>>
>>>>
>>>> Yes
>>>>
>>>>> * a testing/review period that is at least comprehensive enough to 
>>>>> catch
>>>>>   the blaring defects that plagued M3
>>>>
>>>>
>>>>
>>>> yes
>>>>
>>>>>
>>>>> * verification that the src bundle actually builds and results in the
>>>>>   same binary as we are distibuting
>>>>
>>>>
>>>>
>>>> Yes
>>>>
>>>> All of these were the standard way for other projects I've been 
>>>> involved with.  No argument.
>>>>
>>>> But can we, with this in mind, first discuss going forward w/ a 
>>>> release?  We're going to have to bang out a real release process 
>>>> for 1.0, and this is a good opportunity to get started.  I 
>>>> volunteer to help.
>>>
>>>
>>>
>>> Is now a good time to talk about how Geornimo needs its own remote 
>>> maven repo?
>>
>>
>> Heh.  I was just thinking about that, and also about the subject of 
>> OpenEJB - would there be good benefit into bringing it to Geronimo?  
>> We seem to be so interdependent...
>>
>> geir
>>
>>>
>>>
>>> Regards,
>>> Alan
>>>
>>>
>>>
>> -- 
>> Geir Magnusson Jr                                  +1-203-665-6437
>> geirm@apache.org
>>


Mime
View raw message