geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <ge...@apache.org>
Subject Re: Preparation for M4
Date Tue, 05 Jul 2005 10:34:01 GMT

On Jul 4, 2005, at 10:26 PM, Aaron Mulder wrote:

>     I guess we should also decide whether to make Jetty or Tomcat the
> default container, and whether to provide separate builds for each.

I think we should try to do separate builds for Jetty and Tomcat if  
it isn't too much pain.

>
>     Also, we need to decide whether we're planning to run the entire
> TCK on the candidate configuration(s).

I think that would be a good habit to get into.  There's no upside to  
releasing broken software esp after we just announced that we can  
pass the automated test suite.

geir

>
> Aaron
>
> On Mon, 4 Jul 2005, David Blevins wrote:
>
>> On Mon, Jul 04, 2005 at 06:38:23PM -0700, Jeremy Boynes wrote:
>>
>>> David Blevins wrote:
>>>
>>>> On Mon, Jul 04, 2005 at 05:22:36PM -0700, Jeremy Boynes wrote:
>>>>
>>>>
>>>>> David Blevins wrote:
>>>>>
>>>>>
>>>>>> Anything I missed?
>>>>>>
>>>>>>
>>>>>
>>>>> SNAPSHOT elimination so the build is reproducible.
>>>>>
>>>>
>>>>
>>>> Right.  Missed that one for M3 IIRC.
>>>>
>>>>
>>>>
>>>>> Branch so that M4 can stabilize whilst other changes are being  
>>>>> made.
>>>>>
>>>>
>>>>
>>>> We do for every milestone.  Don't expect this to be different.
>>>>
>>>>
>>>>
>>>>> Acceptance test process - how do we know what works (need to  
>>>>> avoid a
>>>>> broken release like M3).
>>>>>
>>>>
>>>>
>>>> That's what I meant by:
>>>>
>>>>  DB> We have a number of people interested in testing.  I'll ping
>>>>  DB> them when I have something ready.
>>>>
>>>> Was thinking to branch when I dish out the binaries for testing.
>>>> Rather than the "surprise, here is a binary" approach we've done in
>>>> the past.  Sounds pretty much like what you are proposing as well.
>>>>
>>>>
>>>
>>> Yes - in the past we've just tagged and moved on. This time I  
>>> think we
>>> should create the branch at the start of the process rather than  
>>> at the
>>> end as there seem to be a lot of pent up changes planned. Yes, we  
>>> may
>>> need to merge some critical changes back to this branch but  
>>> hopefully
>>> this can be kept to a minimum.
>>>
>>> So basically,
>>> * create a branch now, say 1.0-M4-prep
>>> * do the stuff we talking about now on that branch
>>> * cut the final M4 distro
>>> * drop the 1.0-M4-prep branch
>>>
>>> Other work can continue on the trunk without destablizing the M4  
>>> release.
>>>
>>>
>>
>> +1 That's pretty much what I had in mind.
>>
>>
>> -David
>>
>>
>
>

-- 
Geir Magnusson Jr                                  +1-203-665-6437
geirm@apache.org



Mime
View raw message