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: neutral (hermes.apache.org: local policy)
Message-ID: <1104792449.41d9cb816baee@mail.iinet.net.au>
Date: Tue,  4 Jan 2005 06:47:29 +0800
From: Brett Porter <brett@apache.org>
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>
In-Reply-To: <41D9AC69.8090206@bellsouth.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: Internet Messaging Program (IMP) 3.2.1

> >> 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.

> 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 :)

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.

Or, if you are happy to refactor the API within your own project for a while,
keep it pre-1.0. All that you lose is an adoption rate outside of the project,
possibly something you don't want because it isn't ready yet and has been
declared to be that way.

> 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.

Hope this helps!

Cheers,
Brett