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)
Mime-Version: 1.0 (Apple Message framework v750)
In-Reply-To: <448DBBF8.5090903@toolazydogs.com>
References: <448C6A63.8010306@hogstrom.org> <448CB880.1080407@toolazydogs.com>
 <74e15baa0606111755m53e30938kb2e12bc70b4772aa@mail.gmail.com>
 <448CC011.4090901@toolazydogs.com>
 <1C7E07FF-BF7D-4151-92C5-BEA6CD68B4E3@iq80.com>
 <448DBBF8.5090903@toolazydogs.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <411C8E6E-2E9F-43F1-92D1-6F9B8A5A910E@iq80.com>
Content-Transfer-Encoding: 7bit
From: Dain Sundstrom <dain@iq80.com>
Subject: Re: Thoughts about what a release is
Date: Mon, 12 Jun 2006 12:21:08 -0700
To: dev@geronimo.apache.org

On Jun 12, 2006, at 12:09 PM, Alan D. Cabrera wrote:

> Dain Sundstrom wrote:
>> I am a bit torn here, because I agree with both of you depending  
>> on which code we are talking about.  Geronimo is a large project  
>> and I think we will be doing ourselves a disservice if we attempt  
>> to treat all of the code the same.  For example, I think Alan's  
>> comments apply best to the core transaction processing parts of  
>> geronimo, and I think think Aaron's comments apply best to non- 
>> critical parts of the server like the console and tooling.  I  
>> would be upset if someone tried to add a new feature to the core  
>> server in a micro release, but if they say added a new command to  
>> the cli or a new portlet, I wouldn't be upset at all.
>>
>> Can we find a compromise where critical code moves more  
>> conservatively and non-critical code gets more liberal rules?  If  
>> not, I think we should start talking about how to divide up the  
>> code base into independently versioned released components.  This  
>> will take a lot of effort in architecture and organization in our  
>> team.  I'd rather not do it at this time, but maybe the time has  
>> come sooner that I wanted.
>
> Core stuff is more important to you because, well, that's what you  
> work on.  What you consider "fluff" stuff may be critical to others.

Alan, that was not my point.  There is stuff that applications use  
directly (e.g., the tx mgr, ejb container, servlet engine, etc) and  
then there is stuff like the console and sample applications.  If my  
tx mgr, breaks I'm screwed where as if the console breaks, it isn't  
as bad, and if a sample app breaks.  Not all code has the same  
constraints.

> Splitting the product into separate lines would not cause time  
> tested, industry standard, principals to not apply to apply to  
> those new proposed product lines.  I would feel just as strongly  
> about the pieces as I would the whole.

I agree with you, but it would mean that each line would progress at  
its own speed.  I would expect stuff like the console to have several  
major revisions for the next few years, where stuff like the  
transaction processing part of the server would have a major release  
every 18 months.

Anyway, I've made my point, and I will be happy with what ever the  
project agrees on as long as everyone is equally happy (or unhappy).

-dain