Mailing-List: contact axis-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: axis-dev@xml.apache.org
Message-ID: <3D907166.1070404@apache.org>
Date: Tue, 24 Sep 2002 10:06:30 -0400
From: Sam Ruby <rubys@apache.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.1) Gecko/20020826
MIME-Version: 1.0
To: axis-dev@xml.apache.org
Subject: Re: [VOTE] Re: managing change during the 1.0 release process
References: <OF61998F9A.72B2FD04-ON80256C3E.002A4D57@portsmouth.uk.ibm.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Glyn Normington wrote:
> I agree with Sanjiva. In fact I'd go further and say that the RC's should
> be on a branch which will ultimately end in 1.0 (or eventually 1.0.n).
> Compare how Mozilla managed their releases at
> http://www.mozilla.org/roadmap.html. Of course Axis is tiny compared to
> Mozilla, but why not copy a process which seems to work well?
> 
> So, let's put this to the vote: "create a branch for 1.0 and allow only
> agreed changes to be committed to that branch".
> 
> Here's my +1.

;-)

As I mentioned to dims on the phone yesterday, I was hoping that 
somebody would make this suggestion.  The fact is that on an open source 
project we have a number of participants with different foci.  It is 
hard to get everybody pulling in the same direction...

This typically provokes the inevitable question... but don't we all want 
Axis R1 to go out?  The answer is clearly yes, but Glen also wants to 
handle multiple methods on a doc lit, I may want to have us do a little 
bit better on SOAP 1.2 for the upcoming soapbuilders meeting, etc.  If 
any of this can go into R1, great.  If not, then (1) nobody wants it to 
hold up R1, and (2) it should simply go into the next release.

If people don't feel comfortable with branches, I can maintain the R1 
branch by incorporating only those fixes from here on out that are 
properly voted upon in the axis-dev mailing list.

- Sam Ruby