Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Message-ID: <43BE87CC.4030607@hogstrom.org>
Date: Fri, 06 Jan 2006 10:07:56 -0500
From: Matt Hogstrom <matt@hogstrom.org>
User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923)
MIME-Version: 1.0
To: dev@geronimo.apache.org
Subject: Re: Geronimo 2.0
References: <43BD63E6.1080605@toolazydogs.com>
	 <7b3355cb0601051543r1364a1acpa7ba2e4add90b2e0@mail.gmail.com>
	 <43BDB6B5.7090704@toolazydogs.com>
	 <7b3355cb0601051626w404a3069rf1d6a6a70d3303ee@mail.gmail.com>
	 <43BDE335.2060601@gmail.com> <1b5bfeb50601060105t539fa083r@mail.gmail.com>
In-Reply-To: <1b5bfeb50601060105t539fa083r@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

I'll summarize what I think I read.

HEAD will be 2.0 which includes JEE 5 and other significant work (Maven 2 
conversion, etc.)

Branches/1.0 will be where the work for 1.0.x will take place.  It would be from 
this code base we'd branch to a 1.1 when appropriate.

I'm updating my local copy of the branches/1.0 with a version change for 
Geronimo to 1.0.1-SNAPSHOT as well as updating to Tomcay 5.1.15 and Jetty 5.1.10 
to incoroporate the latent fixes.

I'll build and test to make sure its still working (I'm not going to run TCK). 
and then commit these changes back when I've confirmed we're ready to go for 
1.0.1.  Does this sound workable?

Matt

Jacek Laskowski wrote:
> 2006/1/6, John Sisson <jrsisson@gmail.com>:
> 
> 
>>I agree we don't want too many branches.
> 
> 
> Hi John,
> 
> Well, we should get used to them ;) Especially when Java EE 5 work
> takes off. I think there will be more refactorings than ever before.
> It's going to be lots of fun (sarcasm).
> 
> 
>>Will fixes for the 1.0.1 release (hopefully we can get out in a few
>>weeks) be committed to the 1.0 branch and then we create another tag for
>>the 1.0.1 release?
> 
> 
> I'm not too familiar with svn branching/tagging stuff, but AFAIK
> they're just copies of the HEAD. If so, only the disk space limits us
> (which is not the case yet). So, if a need to fix something shows up,
> we will likely have to apply it to HEAD and branch, be it 1.0.1 or 1.1
> depending on its value/importance.
> 
> 
>>Do we have any guesstimates on when we would have JEE 5 development
>>completed?
> 
> 
> I'm pretty sure we don't. Why would that be beneficial?
> 
> 
>>How long it will be before we can deliver a release with some
>>innovations in it, since we previously agreed we want to release
>>frequently?
> 
> 
> I think we should stick with the 3-months period for small releases
> (like 1.0.1) and 6-months period for larger ones (like 1.1) or even
> the most important (like 2.0, 3.0). That could be our goal, and the
> time will show how we go ;)
> 
> 
>>If this is going to be a while then we should discuss the work that is
>>planned for the near future and whether there are enhancements that can
>>be delivered in a releases before JEE 5, and if so, how that could be
>>managed.
> 
> 
> Well, we don't have to wait till JEE 5 development is announced.
> You/anybody can start his/their work on a branch and merge it with the
> HEAD when completed. Of course, the more talk about it the better.
> That's my understanding of how it could (ought to?) work.
> 
> 
>>Could some of the planned enhancements impact the stability of head
>>development and therefore should be done in a branch? E.G. would we have
>>stability problems doing JEE 5 development, re-arch of security, maven 1
>>to maven 2 migration, xbean support, corba impl etc. all in head?
> 
> 
> Yes, after having it completed and heavily tested on a branch.
> 
> The views are indeed mine and I would appreciate any comments on it
> 
> 
>>John
> 
> 
> Jacek
> 
> 
>