Mailing-List: contact directory-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List"
 <directory-dev@incubator.apache.org>
Received-SPF: pass (hermes.apache.org: domain of aok123@bellsouth.net
 designates 205.152.59.71 as permitted sender)
Message-ID: <41D9CD41.5040408@bellsouth.net>
Date: Mon, 03 Jan 2005 17:54:57 -0500
From: Alex Karasulu <aok123@bellsouth.net>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
MIME-Version: 1.0
To: Apache Directory Developers List <directory-dev@incubator.apache.org>
Subject: Re: [VOTE] Directory project releases II
References: <NBBBJGEAGJAKLIDBKJOPMEANPBAB.noel@devtech.com>
 <41D98C98.2080008@apache.org> <41D9AC69.8090206@bellsouth.net>
 <1104792449.41d9cb816baee@mail.iinet.net.au>
In-Reply-To: <1104792449.41d9cb816baee@mail.iinet.net.au>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Brett Porter wrote:

>>>>At the moment, I'm not sure that we have a need to release anything
>>>>separately other than naming and the server, and then gain experience 
>>>>from
>>>>those.  These are only technology previews, anyway, until we exit the
>>>>Incubator.  And once we release separate packages, we increase 
>>>>resistance to
>>>>change (as well as expectations).
>>>>        
>>>>
>
>I agree with this from Noel.
>
>  
>
>>But should these problems be avoided in the first place?  Early adopters 
>>are people who stick close to the dev community like Mark Swanson for 
>>example.  They pay the price as early adopters but we work with them to 
>>sort out those problems lessening their burden.  We try at least :). 
>>    
>>
>
>I agree with this point of view, and it's a bonus to the community. But I think
>the keen early adopters will still find their way in and work with alphas and
>source code releases.
>
>  
>
>>Valid use cases of early adopters may change the API in a way we would 
>>never see while internally managing these APIs.  Knowing early is always 
>>better than knowing the use cases far into development.  
>>    
>>
>
>Perhaps. I think all you are doing is evolving these components at a slower rate
>using your own use cases as a basis. And this project probably has the
>fundamental use cases down pat :)
>I get the feeling that they are designed well enough to evolve to changing
>requirements over time. At what point they get adopted is more about when the
>community can support it.
>
>I've learned this the hard way with Maven. Everybody had a piece of it pre-1.0
>(including me when I was an early adopter), and that later put a lot of pressure
>on getting 1.0 out because of all the conflicting pressures, and more time is
>spent thrashing - helping users get over the problems of early adoption - rather
>than coding and documenting something that people can pick up and work with.
>  
>
Hmmm good points.  Maven got stuck in a tough spot because of this I do 
remember now that you mention it.  It almost made it impossible to forge 
ahead.  We definately do not want these kinds of problems.

>>These early 
>>adopters of API's, are critical for effecting our POV making the API all 
>>that much better when it becomes 1.0.   
>>    
>>
>
>As I've heard before, 1.0 is a start, not an end :)
>  
>
Heh of course but 1.0 is the start of responsibility as you point out 
right below this.

>You do want to make sure your major releases are capable of growing
>backwards-compatibly, but they don't necessarily need to include the kitchen sink.
>  
>
<snip/>

>>This is why I think my fears in 
>>the above paragraph should be overcome.  I still don't want to effect 
>>these early adopters by changing the API but they are most likely going 
>>to be the ones who request or need those changes in the first place.
>>    
>>
>
>I see your point, but I think the costs are going to outway the benefits. The
>early adopters know the risks. Having those not prepared to keep up have to wait
>is not going to kill the directory project.
>
>  
>
>>As an aside I'd like to have a clear understanding of what the 
>>difference is between an internal release verses a public release?  
>>    
>>
>
>Technically, not much. Maybe you'd have a tarball distribution for a public
>release and advertise it on your downloads page, but other stuff is just in the
>repository if people want to use it.
>
>Again, its really about what you are prepared to support and dedicate time to
>building out now even when the objectives don't match the primary product.
>  
>
Thanks for your points they definately do help. 

Alex